Re: Authentication Authorization across wsBinding java Implementation - was : Using security policies in the Bigbank scenario
Hi, With r650032, I have committed some simple additions to support the model and StaX processor for the bunch of policy assertions specified in section 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. I'd wish to optimize this a bit and cut down on some classes in the future. As a start for this here is a question related to the specs and hope somebody is able to help me with some clarity... - Do we need three assertions viz. permitAll, denyAll, allow. Why not just the one as follows: - allow roles=listOfNCNames permitAll=xs:boolean/ So if permitAll is 'true' then all roles is permitted. If it is false then only those roles in the 'roles' attribute is permitted. If it is false and there aren't any roles specified then it is equivalent to 'denyAll'. Thanks - Venkat On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Ok. Please be aware there is an errata associated with the authorization elements. http://www.osoa.org/jira/browse/POLICY-26 On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: +1. I will start looking into this after I am done with some half-finished things on my plate at the moment. Thanks. - Venkat On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Greg Dritschler wrote: Is the authentication policy going to bear any resemblance to the policy described in section 1.7.3.1 of the Policy spec, or is it completely different? Greg I think that Tuscany should implement the authorization - I guess that's what you meant :) - and security identity policies as described in section 1.7.3.1 of the Policy spec, at least. We could start with just implementing the model and XML reading for the elements described in 1.7.3.1 and let the various component implementation extensions handle them (or not) in their own way, but having the model and XML processors would be a good start IMO. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-2239) Support for mutually-exclusive intents
[ https://issues.apache.org/jira/browse/TUSCANY-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatakrishnan resolved TUSCANY-2239. -- Resolution: Fixed Greg, thanks for the re-patch ;-). All committed now - from r650027 to r650031. Support for mutually-exclusive intents -- Key: TUSCANY-2239 URL: https://issues.apache.org/jira/browse/TUSCANY-2239 Project: Tuscany Issue Type: New Feature Components: Java SCA Core Runtime Reporter: Greg Dritschler Assignee: Venkatakrishnan Attachments: tuscany-2239-CompositeWireBuilder.patch, tuscany-2239.patch The SCA Policy specification does not provide a means to define intents which are mutually exclusive. This is a noticeable omission when considering the intents in the SCA Transaction specification which are mutually exclusive by nature (managedTransaction vs. noManagedTransaction, propagatesTransaction vs. suspendsTransaction). There is a need to be able to define intents which are mutually exclusive and for the exclusion to be checked by the SCA runtime to avoid the error of specifying exclusive intents on a single artifact. In addition, there should be rules defined for the handling of mutually exclusive intents which are attached at different levels of a composite or a hierarchy of composites. I have attached a patch to provide the capability to define mutually exclusive intents. This is achieved using a new @excludes attribute on the intent/ element in definitions.xml. For example: intent name=propagatesTransaction constrains=implementation excludes=suspendsTransaction/ @excludes is a list of intents which are mutually-exclusive with the named intent. In order to be effective, a reciprocal definition needs to be made as shown below. intent name=suspendsTransaction constrains=implementation excludes=propagatesTransaction/ The patch makes no assumptions about the relationship of qualified intents to the base intent. Therefore exclusive relationships between qualified intents need to be spelled out. intent name=noManagedTransaction constrains=implementation excludes=managedTransaction managedTransaction.global managedTransaction.local/ A key part of the patch is that there now are two types of intent inheritance with respect to exclusive intents. There is a default inheritance between certain hierarchical elements within a composite. For example consider this snippet from a composite: component name=C1 requires=propagatesTransaction reference name=r1/ reference name=r2/ reference name=r3 requires=suspendsTransaction/ /component In this case the first two references inherit the default intent propagatesTransaction from the component element. However the third reference does not inherit it because it specifies an exclusive intent suspendsTransaction which overrides the component-level default. The second type of inheritance is used when inheriting intents from an implementation (e.g. introspected Java code, or an implementation composite). In this case the intents of the implementation cannot be overridden. Consider this example: component name=D1 implementation.composite name=CZ1/ reference name=r1 requires=suspendsTransaction/ /component Let's assume CZ1 contains the component C1 shown earlier and that it promotes the component reference C1/r1 as r1. C1/r1 has the intent propagatesTransaction. This intent is considered a requirement of the implementation and it cannot be overridden by the using composite. Therefore D1 is in error. -- 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] Resolved: (TUSCANY-2240) Creation of SDO object out of XML (read from an JMS message) is taking too long
It would make pretty much sense to me. Currently we'll try to backport the fix to SDO 1.1 or 1.0. -Ursprüngliche Nachricht- Von: ant elder [mailto:[EMAIL PROTECTED] Gesendet: Samstag, 19. April 2008 09:55 An: tuscany-dev@ws.apache.org Betreff: Re: [jira] Resolved: (TUSCANY-2240) Creation of SDO object out of XML (read from an JMS message) is taking too long This seems like quite a useful fix given the problems it seemed to be causing with the JMS binding, how about an SDO 1.1.1 maintenance release? ...ant On Fri, Apr 18, 2008 at 6:56 PM, Raymond Feng (JIRA) tuscany-dev@ws.apache.org wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Raymond Feng resolved TUSCANY-2240. --- Resolution: Fixed Fixed in trunk under r649628 Creation of SDO object out of XML (read from an JMS message) is taking too long --- Key: TUSCANY-2240 URL: https://issues.apache.org/jira/browse/TUSCANY-2240 Project: Tuscany Issue Type: Bug Components: Java SDO Implementation Affects Versions: Java-SDO-1.0, Java-SCA-1.1 Environment: Windows XP Pro SP2, JDK 1.6_06, SCA 1.1, SDO 1.1 Reporter: Ph.Konradi Assignee: Raymond Feng After I've switched from JMS messages containing Objects to XML (migrated from Tuscany 1.0.1 to 1.1) my application needs around 7 sec to call my service. Before it reacted instantly. I've debugged into to see where the problem is and saw that receiving of the JMS message works still instantly but the processing takes pretty long. Below in the stack trace one can see that a new http connection is opened (???) and I guess that's responsible for the delay. Any explanation for this behaviour? What am I doing wrong? The service's method I'm calling has an argument of complex type. Thanks, Philipp Daemon Thread [ActiveMQ Session Task] (Suspended) PlainSocketImpl.socketConnect(InetAddress, int, int) line: not available [native method] PlainSocketImpl.doConnect(InetAddress, int, int) line: 333 PlainSocketImpl.connectToAddress(InetAddress, int, int) line: 195 PlainSocketImpl.connect(SocketAddress, int) line: 182 Socket.connect(SocketAddress, int) line: 519 Socket.connect(SocketAddress) line: 469 HttpClient(NetworkClient).doConnect(String, int) line: 157 HttpClient.openServer(String, int) line: 394 HttpClient.openServer() line: 529 HttpClient.init(URL, Proxy, int) line: 233 HttpClient.New(URL, Proxy, int, boolean) line: 306 HttpClient.New(URL, Proxy, int) line: 323 HttpURLConnection.getNewHttpClient(URL, Proxy, int) line: 788 HttpURLConnection.plainConnect() line: 729 HttpURLConnection.connect() line: 654 HttpURLConnection.getInputStream() line: 977 URIConverterImpl.createURLInputStream(URI) line: 566 URIConverterImpl.createInputStream(URI) line: 453 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getPackageForURI(String) line: 2294 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).getFactoryForPrefix(String) line: 2188 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createObjectByType(String, String, boolean) line: 1145 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).createTopObject(String, String) line: 1247 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).processElement(String, String, String) line: 883 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, String, String) line: 866 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler(XMLHandler).startElement(String, String, String, Attributes) line: 627 SDOXMLResourceImpl$SDOXMLLoadImpl$XmlHandler.startElement(String, String, String, Attributes) line: 401 StAX2SAXAdapter.handleStartElement(XMLStreamReader, ContentHandler) line: 162 StAX2SAXAdapter.parse(XMLStreamReader, ContentHandler) line: 111 SDOXMLResourceImpl$SDOXMLLoadImpl$1.run() line: 472 AccessController.doPrivileged(PrivilegedExceptionActionT) line: not available [native method] SDOXMLResourceImpl$SDOXMLLoadImpl.load(XMLResource, XMLStreamReader, Map) line: 470 SDOXMLResourceImpl.load(XMLStreamReader, Map) line: 598 XMLDocumentImpl.load(XMLStreamReader, Map) line: 248 XMLStreamHelperImpl.loadDocument(XMLStreamReader, Map) line: 136 XMLStreamHelperImpl.loadObject(XMLStreamReader, Map) line: 98 XMLStreamHelperImpl.loadObject(XMLStreamReader) line: 102 XMLStreamReader2DataObject.transform(XMLStreamReader, TransformationContext) line: 49 XMLStreamReader2DataObject.transform(Object, TransformationContext) line: 34
Re: Should I be able to put a WS binding on a service of a component w/ Composite impl?
On Wed, Apr 2, 2008 at 5:37 PM, Raymond Feng [EMAIL PROTECTED] wrote: Hi, I think your use case is valid. Can you please open a JIRA and attach your test case there? I can investigate. Thanks, Raymond -- From: Scott Kurz [EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 8:07 PM To: tuscany-dev@ws.apache.org Subject: Should I be able to put a WS binding on a service of a component w/ Composite impl? Should this work? composite name=OuterComposite component name=OuterCalculatorComponent service name=OuterCalculatorService binding.ws wsdlElement=/ /service implementation.composite name=calc:InnerComposite/ /component /composite composite name=InnerComposite service name=OuterCalculatorService promote=CalculatorComponent/CalculatorService/ component name=CalculatorComponent service name=CalculatorService/ implementation.java class=calculator.CalculatorServiceImpl/ /component /composite -- I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget with a Composite impl. This causes a problem when RuntimeWireImpl.initInvocationChains() calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain. Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services? I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet. Thanks, Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Did we get a JIRA raise to this? Simon
[jira] Commented: (TUSCANY-2241) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form
[ https://issues.apache.org/jira/browse/TUSCANY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590878#action_12590878 ] ant elder commented on TUSCANY-2241: Many thanks for the fix, it looks ok to me but some of our existing tests have EndpointReferences where its actually invalid so with this fix applied there are test failures (try building binding-ws-axis2 with this fix applied to find them). Could you also supply a patch to fix those? EndpointReference in binding.ws when wsdlElement is not of 'Binding' form - Key: TUSCANY-2241 URL: https://issues.apache.org/jira/browse/TUSCANY-2241 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2, Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2241.patch Web Service Binding Specification v1.0 - Sec 2.1 - Lines 61 to 65: 61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6] EndpointReference 62 that specifies the endpoint for the service or reference. When this element is present along 63 with the wsdlElement attribute on the parent element, the wsdlElement attribute value MUST 64 be of the 'Binding' form as specified above, i.e. WSDL-namespace- 65 URI#wsdl.binding(binding-name). I notice that when an EndpointReference is specified inside binding.ws along with a wsdlElement which is not of 'Binding' form, no warning or error is generated. -- 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-2246) Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery
[ https://issues.apache.org/jira/browse/TUSCANY-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ant elder closed TUSCANY-2246. -- Resolution: Fixed Applied in r650101, thanks for the code Greg. Update DefaultContextFactoryExtensionPoint to use ServiceDiscovery -- Key: TUSCANY-2246 URL: https://issues.apache.org/jira/browse/TUSCANY-2246 Project: Tuscany Issue Type: Improvement Components: Java SCA Core Runtime Reporter: Greg Dritschler Attachments: tuscany-2246.patch Change DefaultContextFactoryExtensionPoint to use ServiceDiscovery to find implementation of context factory. -- 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]
Fwd: Using Tuscany Java SDO with EMF 2.4
Anyone likely to have any time to take a look at this? If its possible to do
something to fix this it would be good to try to get it done in the 1.1.1
release.
...ant
-- Forwarded message --
From: Eric S Rose [EMAIL PROTECTED]
Date: Fri, Apr 18, 2008 at 5:03 PM
Subject: Re: Using Tuscany Java SDO with EMF 2.4
To: [EMAIL PROTECTED]
Frank,
Sorry for the delay in getting back to you, I got busy with some other stuff
that had to be done yesterday.
I've been debugging the problem all morning, and it seems to come down to a
NullPointerException from eStaticClass() in ReferenceImpl. Here's the code
where I'm seeing the exception:
*protected* EClass eStaticClass()
{
* return* SDOPackage.*eINSTANCE*.getReference();
}
SDOPackage.eINSTANCE is null, so SDOPackageImpl.init() is returning null for
some reason. I'm not sure that really answers your question, but I hope it's
helpful.
Thanks,
Eric
[image: Inactive hide details for Frank Budinsky ---04/15/2008 04:28:04
PM---Eric, Theoretically EMF 2.4 should work, because it's supp]Frank
Budinsky ---04/15/2008 04:28:04 PM---Eric, Theoretically EMF 2.4 should
work, because it's supposed to be backward
From:
Frank Budinsky [EMAIL PROTECTED]
To:
[EMAIL PROTECTED]
Date:
04/15/2008 04:28 PM
Subject:
Re: Using Tuscany Java SDO with EMF 2.4
--
Eric,
Theoretically EMF 2.4 should work, because it's supposed to be backward
compatible. Have you tracked down exactly what class is missing and why?
Frank.
Eric S Rose [EMAIL PROTECTED] wrote on 04/15/2008 03:36:49 PM:
David,
EMF 2.2.3 is what I've been using also up until this point. My code
is integrating with a project that's already using EMF 2.4, so I
need to align with the larger project. Based on what I've seen so
far, it doesn't look like that's a possibility.
Thanks,
Eric
[image removed] David Adcox ---04/15/2008 03:10:11 PM---The latest
version I've been using is 2.2.3 - which I believe is what is
currently specified in the
[image removed]
From:
[image removed]
David Adcox [EMAIL PROTECTED]
[image removed]
To:
[image removed]
[EMAIL PROTECTED]
[image removed]
Date:
[image removed]
04/15/2008 03:10 PM
[image removed]
Subject:
[image removed]
Re: Using Tuscany Java SDO with EMF 2.4
The latest version I've been using is 2.2.3 - which I believe is what
is currently specified in the pom files. Is there a reason you need
to use a newer version of EMF?
On Tue, Apr 15, 2008 at 2:09 PM, Eric S Rose [EMAIL PROTECTED] wrote:
Hello all,
Has anyone had any success running Java SDO with EMF 2.4? I'm
running into
a NoClassDefFoundError on SDOUtil.createHelperContext(). I've seen
this on
both the 1.0 and 1.1 releases.
Thanks,
Eric
-
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]
SDO 1.1.1 RC1
There's now a preview SDO 1.1.1 release available at http://people.apache.org/~antelder/tuscany/sdo/1.1.1-RC1/. The only difference between this and the just released 1.1 release is the fix http://issues.apache.org/jira/browse/TUSCANY-2240. I'll leave this a little while before calling a vote to give time for reviews and also would be good if possible to also get a fix for using EMF 2.4 as a user has asked about that. ...ant
[jira] Updated: (TUSCANY-1997) Axis binding does not allow external configuration to increase the number of the maximum connections opened.
[
https://issues.apache.org/jira/browse/TUSCANY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ant elder updated TUSCANY-1997:
---
Attachment: tuscany-binding-ws-axis2-1.0-T1997-T1893.jar
Attached tuscany-binding-ws-axis2-1.0-T1997-T1893.jar which contains the
changes for TUSCANY-1997 and TUSCANY-1893 back-ported to the 1.0 code. The diff
to the base 1.0 code is the following:
Index:
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2BindingInvoker.java
===
---
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2BindingInvoker.java
(revision 630862)
+++
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2BindingInvoker.java
(working copy)
@@ -61,6 +61,7 @@
public static final QName CALLBACK_REFERENCE_REFPARM_QN = new
QName(Constants.SCA10_TUSCANY_NS, CallbackReference);
public static final QName CALLBACK_ID_REFPARM_QN = new
QName(Constants.SCA10_TUSCANY_NS, CallbackID);
public static final QName CONVERSATION_ID_REFPARM_QN = new
QName(Constants.SCA10_TUSCANY_NS, ConversationID);
+public static long GLOBAL_AXIS_TIMEOUT = 12L;
public Axis2BindingInvoker(ServiceClient serviceClient,
QName wsdlOperationName,
@@ -97,7 +98,7 @@
// ensure connections are tracked so that they can be closed by the
reference binding
MessageContext requestMC =
operationClient.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
-requestMC.getOptions().setTimeOutInMilliSeconds(12L);
+requestMC.getOptions().setTimeOutInMilliSeconds(GLOBAL_AXIS_TIMEOUT);
operationClient.execute(true);
Index:
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
===
---
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
(revision 630862)
+++
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2OneWayBindingInvoker.java
(working copy)
@@ -48,7 +48,11 @@
// ensure connections are tracked so that they can be closed by the
reference binding
MessageContext requestMC =
operationClient.getMessageContext(WSDLConstants.MESSAGE_LABEL_OUT_VALUE);
-requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
+//requestMC.getOptions().setProperty(HTTPConstants.REUSE_HTTP_CLIENT,
Boolean.TRUE);
+Options opt = requestMC.getOptions();
+opt.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, Boolean.TRUE);
+opt.setUseSeparateListener(true);
+opt.setProperty(HTTPConstants.AUTO_RELEASE_CONNECTION,Boolean.TRUE);
operationClient.execute(false);
Index:
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
===
---
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
(revision 630862)
+++
src/main/java/org/apache/tuscany/sca/binding/ws/axis2/Axis2ServiceClient.java
(working copy)
@@ -52,8 +52,10 @@
import org.apache.axis2.description.WSDL11ToAxisServiceBuilder;
import org.apache.axis2.description.WSDL2Constants;
import org.apache.axis2.transport.http.HTTPConstants;
+import org.apache.axis2.util.threadpool.ThreadPool;
import org.apache.commons.httpclient.HttpClient;
import org.apache.commons.httpclient.MultiThreadedHttpConnectionManager;
+import org.apache.commons.httpclient.params.HttpConnectionManagerParams;
import org.apache.tuscany.sca.assembly.AbstractContract;
import org.apache.tuscany.sca.binding.ws.WebServiceBinding;
import org.apache.tuscany.sca.contribution.Contribution;
@@ -78,6 +80,8 @@
private ServiceClient serviceClient;
private static final QName SOAP12_INTENT = new
QName(http://www.osoa.org/xmlns/sca/1.0;, soap12);
+public static int httpMaxConnections = 2;
+
public Axis2ServiceClient(RuntimeComponent component,
AbstractContract contract,
WebServiceBinding wsBinding,
@@ -108,7 +112,26 @@
AxisService axisService =
createClientSideAxisService(wsdlDefinition, serviceQName,
portName, new Options());
+HttpClient httpClient = (HttpClient)
configContext.getProperty(HTTPConstants.CACHED_HTTP_CLIENT);
+if (httpClient == null)
+{
+MultiThreadedHttpConnectionManager connectionManager = new
MultiThreadedHttpConnectionManager();
+HttpConnectionManagerParams connectionManagerParams = new
HttpConnectionManagerParams();
+
connectionManagerParams.setDefaultMaxConnectionsPerHost(httpMaxConnections);
+
[jira] Created: (TUSCANY-2248) SOAP intents not being honored
SOAP intents not being honored Key: TUSCANY-2248 URL: https://issues.apache.org/jira/browse/TUSCANY-2248 Project: Tuscany Issue Type: Bug Affects Versions: Java-SCA-1.0 Reporter: Lou Amodeo Hi, It looks like there are a couple issues with the handling of the SOAP version intents with the Web Services binding. The first one is the literal used to identify the SOAP version and the second is the alrogitym used to apply the SOAP intent. 1) Tuscany is currently using soap. soap11 and soap12 for the literals to identify the soap version. I believe these should be soap, soap.1_1, soap.1_2 according to section 2.3.1 of WS Binding specification. 2) During WSDL generation the soap.1_1 intent is not being honored. It appears that the algorithm to determine which soap version to use is incorrect. I believe it should be as follows: I think this is the algorithym: no requires= specifying a soap version or requires=soap - generate soap.1_1 and soap.1_2 port and binding requires = soap.1_1 - generate soap.1_1 port and binding only requires = soap.1_.2 - generate soap.1_2. port and binding only I also see that an http port/binding is generated by Axis2 by default. Since he intetns are based on soap version I would think the http:address should not be generated. wsdl:port name=HelloWorldServiceHttpEndpoint binding=ns:HelloWorldServiceHttpBinding http:address location=http://localhost:8080/axis2/services/HelloWorldService/ /wsdl:port -- 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: [BRAINSTORM] Flexibility in distributed operation and extension implementations - was: Re: Request to propogate the value of a references target= attribute on its associated bindings model object
On Tue, Apr 15, 2008 at 6:10 PM, Yang Lei [EMAIL PROTECTED] wrote: I agree with Simon's emphases on the point of view. I understand Tuscany may prefer one solution over the other. However from extensibility perspective, there need some extension points to enable Tuscany adapters to overwrite the default behavior. I think the thread discussion on reference target and the comparing of 1 and 2 showcase one of the extensibility area : how to resolve reference target for different bindings. I am actually looking beyond just reference target, I see the extensibility in the following areas: 1. When/How to enable a binding to resolve the target endpoint . This include the case to support reference target, and beyond, such as supporting wireByImpl or autoWire. This also include distributed support in case adapters have different ways to support distributed contributions for a given virtual domain. I understand Tuscany has workspace discussions. It may potentially be a solution.I am still waiting to see how workspace is intending to support distributed scenarios or how it can enable late binding on resolving target endpoint. Regardless workspace is the solution or not, we need the flexibility and extensibility to overwrite Tuscany's default behavior on binding end point resolving. 2. When/How the binding resolvable is in used, Some part of the Tuscany code is using binding resolved or not to have different process (see point 3). I think if certain logic outside binding needs to understand if a binding is resolvable, we should make it clear which method achieve it so binding implementations know what to expect. I can see Tuscany code uses binding's URI and targetComponentService today, I think it should be limited to one method only, I am not sure overloading URI is good . 3. When/How to make binding selections on the reference side. I can see Tuscany is trying to remove the unresolvable bindings first from the reference side , then use some algorithm to either pick the default binding if it exists or pick the first on the list. I think we need some plug in point in Tuscany to enable different algorithm from the above default behavior. And the plugin point need to enable late binding so during reference's execution time we can determine a binding is resolvable or not and then use some own prioritizing rules to select the right bindings. I would like to see these discussions concluded with a set of API and some form of API interaction diagrams in the end. Thanks. Yang I can see a couple of scenarios: I thinkand binding selection that we need to enable some extension points for others using other algorism or other - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] I've been thinking about this issue for a few days on and off and it seems to me that the key to this is in the way that we store bindings that have been read in from a composite file. The assembly model starts out with each reference holding all the bindings it is configured with in the composite file. During model build the set of bindings is matched with targets and the resulting list represents the set of resolved bindings complete with URIs identifying target services. These bindings represent the runtime configuration and are used to generate wires. To do late binding we have to maintain the original set of bindings as well as any bindings that have been fully resolved. In this way the reference can resolve targets at runtime with all the information that is used to resolve them at build time. During the first domain implementation I ran across this problem and stored the original list of bindings on the dummy target service that is created for each target. However this is less than satisfactory as this list is not persisted by the processors should the composite be written out again. If we reorganize the bindings such that we have a notion of candidate bindings and resolved bindings then candidate bindings can be used at a later point to create resolved bindings. Much of the builder processing can be done early to associate policy with bindings etc. But the wiring processing needs a bit of thinking about. Anyhow this is not a fully formed thought but I'm throwing this out there as I want to spend some time on this over the next few days and welcome any input. Regards Simon
Renaming SDO CTS
I'd like to rename the CTS svn project to SDO-CTS Please let me know if anyone have issues here, otherwise I want to do this on the next couple days. -- 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: Renaming SDO CTS
Luciano Resende wrote: I'd like to rename the CTS svn project to SDO-CTS Please let me know if anyone have issues here, otherwise I want to do this on the next couple days. +1 from me Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming SDO CTS
It makes it more clear that this is for SDO. Good idea. I assume that this will remain under Java. On 4/21/08, Mike Edwards [EMAIL PROTECTED] wrote: Luciano Resende wrote: I'd like to rename the CTS svn project to SDO-CTS Please let me know if anyone have issues here, otherwise I want to do this on the next couple days. +1 from me Yours, Mike. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Renaming SDO CTS
Luciano Resende wrote: I'd like to rename the CTS svn project to SDO-CTS Please let me know if anyone have issues here, otherwise I want to do this on the next couple days. +1 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (TUSCANY-2241) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form
[ https://issues.apache.org/jira/browse/TUSCANY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2241: - Attachment: TUSCANY-2241.patch This should take care of the failing tests. EndpointReference in binding.ws when wsdlElement is not of 'Binding' form - Key: TUSCANY-2241 URL: https://issues.apache.org/jira/browse/TUSCANY-2241 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2, Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2241.patch, TUSCANY-2241.patch Web Service Binding Specification v1.0 - Sec 2.1 - Lines 61 to 65: 61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6] EndpointReference 62 that specifies the endpoint for the service or reference. When this element is present along 63 with the wsdlElement attribute on the parent element, the wsdlElement attribute value MUST 64 be of the 'Binding' form as specified above, i.e. WSDL-namespace- 65 URI#wsdl.binding(binding-name). I notice that when an EndpointReference is specified inside binding.ws along with a wsdlElement which is not of 'Binding' form, no warning or error is generated. -- 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-2241) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form
[ https://issues.apache.org/jira/browse/TUSCANY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated TUSCANY-2241: - Attachment: (was: TUSCANY-2241.patch) EndpointReference in binding.ws when wsdlElement is not of 'Binding' form - Key: TUSCANY-2241 URL: https://issues.apache.org/jira/browse/TUSCANY-2241 Project: Tuscany Issue Type: Bug Components: Java SCA Verification Tests Affects Versions: Java-SCA-1.2, Java-SCA-Next Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: Java-SCA-Next Attachments: TUSCANY-2241.patch Web Service Binding Specification v1.0 - Sec 2.1 - Lines 61 to 65: 61 • /binding.ws/wsa:EndpointReference - optional WS-Addressing [6] EndpointReference 62 that specifies the endpoint for the service or reference. When this element is present along 63 with the wsdlElement attribute on the parent element, the wsdlElement attribute value MUST 64 be of the 'Binding' form as specified above, i.e. WSDL-namespace- 65 URI#wsdl.binding(binding-name). I notice that when an EndpointReference is specified inside binding.ws along with a wsdlElement which is not of 'Binding' form, no warning or error is generated. -- 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: Registering ModuleActivators without specifying a META-INF/services/org.apache.tuscany.sca.core.ModuleActivator file
Hi, Yes. I'm interested in only a subset of Tuscany and not the entire runtime. Thanks for the answer. The ModuleActivators I'm trying to use are WSDLInterfaceRuntimeModuleActivator, JavaInterfaceRuntimeModuleActivator, and JavaRuntimeModuleActivator. This leads to another question. For the JavaRuntimeModuleActivator, it seems to require bootstraping code which adds a ContextFactoryExtensionPoint/DefaultContextFactoryExtensionPoint to the registry. However ContextFactoryExtensionPoint and DefaultContextFactoryExtensionPoint are non SPI. What do I need in my bootstraping code in order for me to use JavaRuntimeModuleActivator without SPI violations? Thanks. Richard Mah
Re: Implementing the tutorial's store UI as an assembly of widgets
Jean-Sebastien Delfino wrote: I've added the beginning of a store-mashup module under tutorial/. It's just a starting point but I'd like to use it to illustrate how the store application can be implemented with multiple widgets assembled in a sort of mashup. Right now it just has two widgets, the original store page in one HTML iframe and a google map in another (displaying the origin of the fruits in the catalog when you click them), but in the next few days I'll try to make it more module and split the store in two parts, a catalog widget and a shopping cart widget. I've also started to look at how to use DOJO and OpenAjax in that particular scenario, I'll post an update and more thoughts about it later, probably next week. Here's an update. In SVN revision r650222 of the tutorial [1] I've made some changes to show how to use the OpenAjax Javascript Hub [2][3] to send events from one widget to the other, instead of hardcoding a call to a Javascript even handling function. It seems pretty simple and a nice way to communicate between widgets without tying them together. [1] http://svn.apache.org/viewvc?view=revrevision=650222 [2] http://openajaxallianc.svn.sourceforge.net/svnroot/openajaxallianc/hub/tags/hub10_build117/release/OpenAjax.js [3] http://sourceforge.net/project/showfiles.php?group_id=175671package_id=201731 -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-2249) Updates to ComponentContext's vtest
Updates to ComponentContext's vtest --- Key: TUSCANY-2249 URL: https://issues.apache.org/jira/browse/TUSCANY-2249 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Reporter: Yee-Kang Chang More vtest test cases for ComponentContext API. -- 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-2249) Updates to ComponentContext's vtest
[ https://issues.apache.org/jira/browse/TUSCANY-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Kang Chang updated TUSCANY-2249: Attachment: ComponentContextUpdatesJIRA2249.patch Updates to ComponentContext's vtest --- Key: TUSCANY-2249 URL: https://issues.apache.org/jira/browse/TUSCANY-2249 Project: Tuscany Issue Type: Test Components: Java SCA Verification Tests Reporter: Yee-Kang Chang Attachments: ComponentContextUpdatesJIRA2249.patch More vtest test cases for ComponentContext API. -- 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-2250) ComponentContext.getRequestContext() does NOT return null when there's no request
ComponentContext.getRequestContext() does NOT return null when there's no request - Key: TUSCANY-2250 URL: https://issues.apache.org/jira/browse/TUSCANY-2250 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Yee-Kang Chang The specification states the below for ComponentContext.getRequestContext(): getRequestContext() - Returns the context for the current SCA service request, or null if there is no current request or if the context is unavailable. A composite-scoped component annotated with @EagerInit was defined. In its @Init method, attempt was made to retrieve the RequestContext via ComponentContext.getRequestContext(). A RequestlContextImpl object that threw Exception when its method was invoked was returned when null was expected. The test case that illustrates is in the patch posted via JIRA 2249. -- 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: Some questions for workspace module in Tuscany
Simon Laws wrote: Hi A few clarifications in line. Simon On Fri, Apr 4, 2008 at 8:24 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Yang Lei wrote: Hello, I have the following usage scenarios that I currently use EmbeddedSCADomain's ContributionService to accomplish. When I look at the new set of workspace modules, I wonder how it can be accomplished by using this new set of workspace related apis. And what the pros/cons if I switch to use workspace: Scenario 1: I need to load a SCA contribution to iterate the deployables , each deployable composite needs to resolve the componentType: from java annotation, from componentType file, from QName of another composite file which may be imported from another contribution by using import namespace The way I support it today is like what itest/contribution-import-export does: ContributionService contributionService = domain.getContributionService(); ... Contribution consumerContribution = contributionService.contribute(...); Composite consumerComposite = consumerContribution.getDeployables().get(0); domain.getDomainComposite().getIncludes().add(consumerComposite); domain.buildComposite(consumerComposite); Scenario 2: I need to start a contribution 's deployable composite with a domain. Again I use the same approach as in itest/contribution-import-export, besides the above code I add the following // Start Components from my composite domain.getCompositeActivator().activate(consumerComposite); domain.getCompositeActivator().start(consumerComposite); Now I am looking into how to accomplish the above by using workspace related APIs. I started looking at a workspace test case: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java I have the following observations: 1. The bootstraping of Tuscany extension points are outside the workspace. I can see a lot code in init() to do bootstraping. I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, even though it may happen that scenario1 bootstrapping is only a subset of scenario 2's . If we are worried that one fit for all bootstrapping is an overhead for scenario 1, maybe we can have some 2 stage bootstrapping: composite model resolved, composite start. Or we can even break into 3 : composite model load from scdl no resolving componentType, composite model resolved, composite start... I'm interested in what you say about bootstrapping being associated with a domain. The code you have been looking at in the domain itest I believe contains all the detailed steps you need to go through in order to read contributions, understand the dependencies between them, read and resolve them and finally run some composite that is contained in the contributions. Is your main concern here that these steps are just too complicated and that you would like them wrapped up (which is, as Sebastien suggests, relatively straightforward to do as long as we can agree that the steps are fundamentally doing the right kinds of things). Or is there some more fundamental issue with the concepts that concerns you. In particular you say I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, But if I take the init code from the test you have been looking at and run it twice both copies of the runtime would have the same sets of extensions and bindings as the code loads these from the runtime classpath. As Sebastien describes below the workspace is independent of the rest of the code in the init method in that that is just holds onto contributions and doesn't care how those contributions were generated. Makes sense. I am not sure that the bootstrap code should be 'tied to a domain', but I can do the following: - Provide a few pre-canned init methods that bootstrap the subset of a Tuscany runtime required for your scenarios. I'll start with these: a) list deployables in a contribution b) resolve deployables given the set of available contributions - Come up with samples (easier to understand than test cases) showing how to use the init methods and the current SPIs to implement these scenarios. I'll probably keep the init method in each sample to start with, and then as we
Re: Some questions for workspace module in Tuscany
+1 on the proposed refactoring. Thanks, Raymond -- From: Jean-Sebastien Delfino [EMAIL PROTECTED] Sent: Monday, April 21, 2008 3:34 PM To: tuscany-dev@ws.apache.org Subject: Re: Some questions for workspace module in Tuscany Simon Laws wrote: Hi A few clarifications in line. Simon On Fri, Apr 4, 2008 at 8:24 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Yang Lei wrote: Hello, I have the following usage scenarios that I currently use EmbeddedSCADomain's ContributionService to accomplish. When I look at the new set of workspace modules, I wonder how it can be accomplished by using this new set of workspace related apis. And what the pros/cons if I switch to use workspace: Scenario 1: I need to load a SCA contribution to iterate the deployables , each deployable composite needs to resolve the componentType: from java annotation, from componentType file, from QName of another composite file which may be imported from another contribution by using import namespace The way I support it today is like what itest/contribution-import-export does: ContributionService contributionService = domain.getContributionService(); ... Contribution consumerContribution = contributionService.contribute(...); Composite consumerComposite = consumerContribution.getDeployables().get(0); domain.getDomainComposite().getIncludes().add(consumerComposite); domain.buildComposite(consumerComposite); Scenario 2: I need to start a contribution 's deployable composite with a domain. Again I use the same approach as in itest/contribution-import-export, besides the above code I add the following // Start Components from my composite domain.getCompositeActivator().activate(consumerComposite); domain.getCompositeActivator().start(consumerComposite); Now I am looking into how to accomplish the above by using workspace related APIs. I started looking at a workspace test case: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/itest/domain/src/test/java/org/apache/tuscany/sca/itest/domain/ContributionSPIsTestCase.java I have the following observations: 1. The bootstraping of Tuscany extension points are outside the workspace. I can see a lot code in init() to do bootstraping. I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, even though it may happen that scenario1 bootstrapping is only a subset of scenario 2's . If we are worried that one fit for all bootstrapping is an overhead for scenario 1, maybe we can have some 2 stage bootstrapping: composite model resolved, composite start. Or we can even break into 3 : composite model load from scdl no resolving componentType, composite model resolved, composite start... I'm interested in what you say about bootstrapping being associated with a domain. The code you have been looking at in the domain itest I believe contains all the detailed steps you need to go through in order to read contributions, understand the dependencies between them, read and resolve them and finally run some composite that is contained in the contributions. Is your main concern here that these steps are just too complicated and that you would like them wrapped up (which is, as Sebastien suggests, relatively straightforward to do as long as we can agree that the steps are fundamentally doing the right kinds of things). Or is there some more fundamental issue with the concepts that concerns you. In particular you say I think I would prefer the bootstrapping are tied with a given domain, as all the workspace usage for a given domain should have the same bootstrapping on the object model and what kind of bindingTypes or implementationTypes are supported. If it can be done it that way, then I do not need to bootstrap everytime I use workspace, and I can keep both bootstrapping of scenario 1 and 2 consistent, But if I take the init code from the test you have been looking at and run it twice both copies of the runtime would have the same sets of extensions and bindings as the code loads these from the runtime classpath. As Sebastien describes below the workspace is independent of the rest of the code in the init method in that that is just holds onto contributions and doesn't care how those contributions were generated. Makes sense. I am not sure that the bootstrap code should be 'tied to a domain', but I can do the following: - Provide a few pre-canned init methods that bootstrap the subset of a Tuscany runtime required for your scenarios. I'll start with these: a) list deployables in a contribution b) resolve
Re: Authentication Authorization across wsBinding java Implementation - was : Using security policies in the Bigbank scenario
Hi, I assume you are implementing the syntax in OSOA SCA spec 1.0. Do we know if http://www.osoa.org/jira/browse/POLICY-26 is an officially accepted proposal? Thanks, Raymond -- From: Venkata Krishnan [EMAIL PROTECTED] Sent: Monday, April 21, 2008 12:20 AM To: tuscany-dev@ws.apache.org Subject: Re: Authentication Authorization across wsBinding java Implementation - was : Using security policies in the Bigbank scenario Hi, With r650032, I have committed some simple additions to support the model and StaX processor for the bunch of policy assertions specified in section 1.7.3-Implementation-Security-Policy of the PolicyFwk Specs. I'd wish to optimize this a bit and cut down on some classes in the future. As a start for this here is a question related to the specs and hope somebody is able to help me with some clarity... - Do we need three assertions viz. permitAll, denyAll, allow. Why not just the one as follows: - allow roles=listOfNCNames permitAll=xs:boolean/ So if permitAll is 'true' then all roles is permitted. If it is false then only those roles in the 'roles' attribute is permitted. If it is false and there aren't any roles specified then it is equivalent to 'denyAll'. Thanks - Venkat On Thu, Mar 6, 2008 at 11:43 PM, Greg Dritschler [EMAIL PROTECTED] wrote: Ok. Please be aware there is an errata associated with the authorization elements. http://www.osoa.org/jira/browse/POLICY-26 On Wed, Mar 5, 2008 at 1:51 AM, Venkata Krishnan [EMAIL PROTECTED] wrote: +1. I will start looking into this after I am done with some half-finished things on my plate at the moment. Thanks. - Venkat On Wed, Mar 5, 2008 at 12:00 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Greg Dritschler wrote: Is the authentication policy going to bear any resemblance to the policy described in section 1.7.3.1 of the Policy spec, or is it completely different? Greg I think that Tuscany should implement the authorization - I guess that's what you meant :) - and security identity policies as described in section 1.7.3.1 of the Policy spec, at least. We could start with just implementing the model and XML reading for the elements described in 1.7.3.1 and let the various component implementation extensions handle them (or not) in their own way, but having the model and XML processors would be a good start IMO. Any thoughts? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[GSoC] Accepted Student Proposals for 2008 Announced
It's now official, Google has announced the accepted student proposals for 2008 [1] and the ASF accepted proposals is also available [2].It's very good to see that all the effort done by the Tuscany Community has now materialized as 6 excellent proposals accepted. I'd also want to take this opportunity to welcome the new students to the community, and of course, thanks for all the Tuscany Community that steeped up as mentors and are going to be helping these students trough out the summer and hopefully for a much bigger period of time. See below the Apache Tuscany approved student proposals Tuscany SCA Support in the Geronimo Admin Console by Thilina Mahesh Buddhika, mentored by Ant Elder Simplify the development of Map/Reduce applications and their integration with various sources of information by Christopher Trezzo, mentored by Jean-Sebastien Delfino Allow Google Android applications to easily consume business services (version 2.0 - 6Apr2008 @17.50) by Oscar Castaneda, mentored by Adriano Crestani Campos Integrate Google Services in SCA Compositions by Douglas Siqueira Leite, mentored by Luciano Resende CORBA support for Apache Tuscany by Wojtek, mentored by Zhaohui Feng Integrate Google services in SCA compositions（Apache Tuscany） by Haibo Zhao, mentored by Luciano Resende [1] http://code.google.com/soc/2008/ [2] http://code.google.com/soc/2008/asf/about.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
Re: [GSoC] Accepted Student Proposals for 2008 Announced
Hi all, It is a great pleasure to get accepted for GSoC 2008 and to continue with Tuscany Community. I make this an opportunity to thank the Tuscany community for their great support to make this a success. All the suggestions and incentives given by the community were really helpful. I would like thank especially to my mentor, Ant for his massive support through out the past few weeks. I will try level best to complete this project with a high quality. I am sure Tuscany community will help me with the the future work as well. Thanks. best regards, / thilina 2008/4/22 Luciano Resende [EMAIL PROTECTED]: It's now official, Google has announced the accepted student proposals for 2008 [1] and the ASF accepted proposals is also available [2].It's very good to see that all the effort done by the Tuscany Community has now materialized as 6 excellent proposals accepted. I'd also want to take this opportunity to welcome the new students to the community, and of course, thanks for all the Tuscany Community that steeped up as mentors and are going to be helping these students trough out the summer and hopefully for a much bigger period of time. See below the Apache Tuscany approved student proposals Tuscany SCA Support in the Geronimo Admin Console by Thilina Mahesh Buddhika, mentored by Ant Elder Simplify the development of Map/Reduce applications and their integration with various sources of information by Christopher Trezzo, mentored by Jean-Sebastien Delfino Allow Google Android applications to easily consume business services (version 2.0 - 6Apr2008 @17.50) by Oscar Castaneda, mentored by Adriano Crestani Campos Integrate Google Services in SCA Compositions by Douglas Siqueira Leite, mentored by Luciano Resende CORBA support for Apache Tuscany by Wojtek, mentored by Zhaohui Feng Integrate Google services in SCA compositions（Apache Tuscany） by Haibo Zhao, mentored by Luciano Resende [1] http://code.google.com/soc/2008/ [2] http://code.google.com/soc/2008/asf/about.html -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://people.apache.org/%7Elresende http://lresende.blogspot.com/
[jira] Updated: (TUSCANY-2251) Problem with 1.2 RC4 with simple JavaBean
[ https://issues.apache.org/jira/browse/TUSCANY-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nishant Joshi updated TUSCANY-2251: --- Attachment: SimpleBeanProblem.zip Sample for more detail... SimpleBeanProblem.zip Problem with 1.2 RC4 with simple JavaBean - Key: TUSCANY-2251 URL: https://issues.apache.org/jira/browse/TUSCANY-2251 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.2 Environment: Eclipse 3.3, Tuscany SCA 1.2 - RC4 Reporter: Nishant Joshi Fix For: Java-SCA-1.2 Attachments: SimpleBeanProblem.zip Hi there, I have one sample which was perfectly working with 1.0 incubating... when i have tried same with 1.2 RC4 all the data come from client was null for all the values for a simple bean. Please note that I m creating Client on Eclipse 3.3... using WebService client generation facility of eclipse... I m attaching detail for more detail... When tried same with SCA client it was giving me perfect result... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TUSCANY-2251) Problem with 1.2 RC4 with simple JavaBean
Problem with 1.2 RC4 with simple JavaBean - Key: TUSCANY-2251 URL: https://issues.apache.org/jira/browse/TUSCANY-2251 Project: Tuscany Issue Type: Bug Components: Java SCA Data Binding Runtime Affects Versions: Java-SCA-1.2 Environment: Eclipse 3.3, Tuscany SCA 1.2 - RC4 Reporter: Nishant Joshi Fix For: Java-SCA-1.2 Attachments: SimpleBeanProblem.zip Hi there, I have one sample which was perfectly working with 1.0 incubating... when i have tried same with 1.2 RC4 all the data come from client was null for all the values for a simple bean. Please note that I m creating Client on Eclipse 3.3... using WebService client generation facility of eclipse... I m attaching detail for more detail... When tried same with SCA client it was giving me perfect result... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
