Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario

2008-04-21 Thread Venkata Krishnan 
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: -


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

2008-04-21 Thread Venkatakrishnan (JIRA) 

 [ 
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 
>  element in definitions.xml.  For example:
>  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.
>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.
>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:
> 
> 
> 
> 
> 
> 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:
> 
> 
> 
> 
> 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

2008-04-21 Thread Konradi, Philipp (CT) 
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.(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(PrivilegedExceptionAction) 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

Re: Should I be able to put a WS binding on a service of a component w/ Composite impl?

2008-04-21 Thread Simon Laws 
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: 
> Subject: Should I be able to put a WS binding on a service of a component
> w/ Composite impl?
>
>
>  Should this work?
> >
> >
> >
> > 
> >   
> > 
> >   
> > 
> > 
> >   
> > 
> >
> >
> > 
> >> promote="CalculatorComponent/CalculatorService"/>
> >
> >   
> >   
> >   
> >   
> > 
> >
> >
> > --
> >
> > 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

2008-04-21 Thread ant elder (JIRA) 

[ 
https://issues.apache.org/jira/browse/TUSCANY-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.  65 URI>#wsdl.binding().
> 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

2008-04-21 Thread ant elder (JIRA) 

 [ 
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

2008-04-21 Thread ant elder 
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

2008-04-21 Thread ant elder 
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.

2008-04-21 Thread ant elder (JIRA) 

 [ 
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

2008-04-21 Thread Lou Amodeo (JIRA) 
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. 


  http://localhost:8080/axis2/services/HelloWorldService"/>

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

2008-04-21 Thread Simon Laws 
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

2008-04-21 Thread Luciano Resende 
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

2008-04-21 Thread Mike Edwards 

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

2008-04-21 Thread haleh mahbod 
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

2008-04-21 Thread Jean-Sebastien Delfino 

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

2008-04-21 Thread Vamsavardhana Reddy (JIRA) 

 [ 
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.  65 URI>#wsdl.binding().
> 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

2008-04-21 Thread Vamsavardhana Reddy (JIRA) 

 [ 
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.  65 URI>#wsdl.binding().
> 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

2008-04-21 Thread Richard Mah 
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

2008-04-21 Thread Jean-Sebastien Delfino 

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=rev&revision=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=175671&package_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

2008-04-21 Thread Yee-Kang Chang (JIRA) 
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

2008-04-21 Thread Yee-Kang Chang (JIRA) 

 [ 
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

2008-04-21 Thread Yee-Kang Chang (JIRA) 
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

2008-04-21 Thread Jean-Sebastien Delfino 

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 

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 work through mor

Re: Some questions for workspace module in Tuscany

2008-04-21 Thread Raymond Feng 

+1 on the proposed refactoring.

Thanks,
Raymond
--
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
Sent: Monday, April 21, 2008 3:34 PM
To: 
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 

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 avail

Re: Authentication & Authorization across wsBinding & java Implementation - was : Using security policies in the Bigbank scenario

2008-04-21 Thread Raymond Feng 

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: 
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: -
   

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

2008-04-21 Thread Luciano Resende 
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

2008-04-21 Thread Thilina Buddhika 
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://lresende.blogspot.com/
>

[jira] Updated: (TUSCANY-2251) Problem with 1.2 RC4 with simple JavaBean

2008-04-21 Thread Nishant Joshi (JIRA) 

 [ 
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

2008-04-21 Thread Nishant Joshi (JIRA) 
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.