Re: Trouble with Maven including rampart.mar as dependency

[Deepal jayasinghe]

Venkata Krishnan wrote:
> Hi,
>
> I am trying use rampart for security support on the ws-binding in
> Apache Tuscany Java SCA.  I included the rampart.mar as dependency in
> the axis2 ws binding pom file (
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/pom.xml)
> as follows : -
>
> 
> org.apache.rampart
> rampart
> 1.2
> mar
> runtime
> 
>
> While Maven successfully downloads and installs rampart.mar it seems
> like its not including it in the build classpath as a result of which
> I get a 'trying to engage an unavailable module' exception.  Am I
> missing something here?  Could somebody help with hints ?  Thanks.
>
> PS : When I imported the project into eclipse I found that the
> .classpath that maven generates does not contain the .mar file. 
> Including this explicitly runs everything cleanly within eclipse. 
> Hence my suspicion on Maven ever doing anything with the .mar file.
>
> Thanks
> - Venkat
Please use Rampart 1.3 instead of 1.2.

Thanks
Deepal

-- 
Thanks,
Deepal

"The highest tower is built one brick at a time"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Including the XQuery sample in the next release?

[Jean-Sebastien Delfino]

Vasil Vasilev wrote:

Hi,

Some thoughts about the example simplification - really it would be good to simplify the sample, but the client+server scenario should remain as JUnit test I think. 


+1 to keep the client/server scenario, I'd suggest to create an itest 
module for it, something like itest/implementation-xquery.



You can see below some problems I currently have exactly with this scenario.

I started looking at the following issues:

1. sharing common Configuration object
2. Being able to directly implement a WSDL interface


Unfortunately I was not able to execute the sample JUnit test after I checked out the latest sources. The problem occurs when executing the scenario in which the XQuery component is a remote one and is exposed as Web Service. 
When I investigated the problem it appeared that the "targetOperation" of the DataTransformationInteceptor on the server side (i.e. the one that is called by Axis2ServiceProvider.invokeTarget) has input type with SDO data bindings of the input parameters, while I should have had Saxon type data binding.
  


Not sure... Raymond, any idea? could this be caused by a recent change 
to the DataBinding framework?



In the contrary if I look at the "contract" variable of the 
Axis2ServiceProvider - the databinding of the input parameters of the operation are 
correct.

Is there something done recently in this direction, which could have led to the 
problem?

--

One more note: Currently it will be possible (I will verify it after i have 
finished with the implementation :) ) for an XQuery component to implement a 
WSDL interface, bt it will not be possible to call a reference which has WSDL 
interface. At least i do not see how, because Saxon wants a java interface, 
which to be called. Can we think of some workaround?
  


How about asking on the saxon-help mailing list?


Bye, Vasil
  

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Add AllowsPassByReference methods to o.a.t.s.a.Implementation?

[ant elder]

I'd like to add AllowsPassByReference methods to the Tuscany Implementation
Interface. Currently the Java and OSGi impls have AllowsPassByReference
code, potentially other impls could use this as well, and with the
pass-by-value code moved out of the Java implementation it really needs a
generic way to see if an implementation needs a copy done.

   ...ant

Re: Including the XQuery sample in the next release?

[Jean-Sebastien Delfino]

Jean-Sebastien Delfino wrote:

Vasil Vasilev wrote:

Hi,

Isn't in the official repository some older version of Saxon. May be 
we could try to run the prototype with this older version.


Bye, Vasil


  


If the Saxon project really doesn't want to publish newer JARs then I 
guess we're going to have to use the 8.7 version already on ibiblio.org.


In the longer term, this also gives us a good opportunity to think 
about making XQuery processor implementations pluggable, as you 
already suggested :)




Hi Vasil,

Did you manage to backport and run the XQuery implementation code on 
Saxon 8.7? or are there any issues with 8.7 and we should try to see 
what we can do to get 8.9 published in a Maven repos?


Thanks

--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)

[Simon Nash]

Comments inline.

  Simon

Jean-Sebastien Delfino wrote:


Comments inline.

[snip]
Simon Nash wrote:


I agree that we need a conclusion.  I believe the detailed proposal below
supports all the SCA semantics and I'd like to propose that we go with it
for Tuscany 1.0.

Any comments, questions, agreement, or disagreement?

  Simon



I was initially thinking that the Callback EPR should be a separate 
header outside of the To EPR but the code snippet that you put together 
to simulate the SCA built-in callback (at the bottom of that email) 
convinced me that I was wrong about it :)


So I'm +1 with your proposal in [1]:

Request message

 
   ...URI of the service being invoked...
   
 callback-A01
 conversation-006
 
   
 ...URI of the service for the 
callback...

 
 
 
  


Callback message:

 
   ...URI of the service for the callback...
   
 callback-A01
 conversation-006
   
 


In plain text:
- CallbackID flows as a reference parameter of the "To" EPR
- ConversationID flows as a reference parameter of the "To" EPR
- CallbackReference is a well formed EPR and flows as a reference 
parameter of the "To" EPR



I can see the benefit of this, as it makes the pseudo-code below a
closer match for what is flowing on the wire, with an SCA callable
reference always being serialized as a WS-Addressing EPR.  So I am
+1 with using a well-formed WS-Addressing EPR for the callback EPR.

I think that we should propose this mapping to the OASIS SCA Bindings 
workgroup. Different implementations of SCA should follow the same 
mapping if we want them to interoperate over Web Services for example.



Yes, I agree.  I'll ask the chair of the newly formed OASIS TC how we
should raise this as formal issue for the TC.


[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html


[snip]



Yes, I'm proposing what I said in [1] with a 

reference parameter under the wsa:To stateful EPR.  Looking at this 
again,

it could be slightly improved to eliminate the 
and  within , giving:


   
  ...URI of the service being invoked...
  
  callback-A01

conversation-006
  
 ...URI of the service for the callback...
  
  
   


This requires the  to be "fluffed up" into
a  when the callback is sent, with the
 and  as its reference
parameters:


   
  ...URI of the service for the 
callback...

  
  callback-A01

conversation-006
  
   


  Simon



I'm not keen on doing that. I'd prefer to stick to your initial proposal 
which seems cleaner to me, using the same standard form to represent the 
CallbackReference EPR in the request message and the To EPR in the 
callback message.



+1 for going with the alternative version above instead of this version.





 @Service(Client.class)
 class Client {
ComponentContext componentContext;
Writer writer;

write(inputData) {
   target = componentContext.getServiceReference(Writer.class, 
"writer");

   self = componentContext.createSelfReference();
   id = new UUID();
   target.setCallbackID(id);
   self.setCallbackID(id);
   target.setCallback(self);
   target.getService().asyncWrite(target, inputData);
}

written(myReference) {
   // data  has been written
}
 }

 @Service(Writer.class)
 class Writer {

@OneWay
asyncWrite(myReference, inputData) {
   // actually write the data

   clientReference = myReference.getCallback();
   clientReference.getService().written(clientReference);
}
 }



I'd suggest a small variation of this pseudo-code, to be more in line 
with the protocol that you proposed (the callbackID doesn't flow in the 
CallbackReference in the request message):


@Service(Client.class)
class Client {
   ComponentContext componentContext;
   Writer writer;

   write(inputData) {
  target = componentContext.getServiceReference(Writer.class, 
"writer");

  self = componentContext.createSelfReference();
  id = new UUID();
  target.setCallbackID(id);
  target.setCallback(self);
  target.getService().asyncWrite(target, inputData);
   }

   written(myReference) {
  // data  has been written
   }
}

@Service(Writer.class)
class Writer {

   @OneWay
   asyncWrite(myReference, inputData) {
  // actually write the data

  clientReference = myReference.getCallback();
  clientReference.setCallbackID(myReference.getCallbackID());
  clientReference.getService().written(clientReference);
   }
}


+1 for this change.  It makes the pseudo-code match exactly with the
protocol on the wire.

  Simon


--

Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Resetting state of service references at conversation end

[Jean-Sebastien Delfino]

I'm overall +1 with this proposal, with some minor changes described in 
comments inline.


Raymond Feng wrote:

Hi,

As we agreed, the conversation id alone is not sufficient to deal with 
conversations. We need to maintain the state of the conversations 
(STARTED, ENDED or EXPIRED).


Right, if I understand correctly we need to keep the state of a 
conversation in a central place in a Tuscany runtime that all 
participants can point to, allowing one to end the conversation, and the 
other conversation participants to see that it has ended.




I propose that we do the following:

1) Define a ConversationManager like:

public interface ConversationManager() {
   String start(String conversationID);  // If the conversationID is 
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the 
conversation ID is not always a String.


Change start to startConversation to make clear that it's the 
conversation that you're starting and not the ConversationManager.


Also I think it's better to return the Conversation object (see below 
for its contents).



   void end(String conversationID);  // Ends the conversation


void endConversation(Conversation conversation)

Don't you need another method to make a conversation expire?

   ConversationState getConversationState(String conversationID); // 
Get the state of the conversation


Conversation getConversation(Object conversationID)


   void register(ConversationListener listener); // Register a listener
   void unregister(ConversationListener listener); // Remove a listener


Let's try to be consistent with other listener interfaces:
addListener(ConversationListener listener)
removeListener(ConversationListener listener)

Also, these methods should be on the Conversation object described below 
I think.



}

public interface ConversationListener() {
   void conversationStarted(String conversationID);
   void conversationEnded(String conversationID);
   void conversationExpired(String conversationID);
}


Pass Conversation conversation instead of String conversationID.

If the methods are on the Conversation object instead of the 
ConversationManager they can be simpler I think:

public interface ConversationListener() {
  void conversationStarted();
  void conversationEnded();
  void conversationExpired();
}




public enum ConversationState {
   STARTED, ENDED, EXPIRED
}


class Conversation {
 ConversationState state;
 Object conversationID;
}

Having this class allows you to evolve it over time, does not rely on 
the fact that conversations are stored in a map, and also IMO better 
represents what you'll store in persistent storage in the future.


Do we we need an expiry time field here as well?



2) The proxy or callable references will only keep the conversation 
ID. Whenever the Conversation object is referenced or we need to 
perform any actions to a conversation, we use the ID to look up the 
state of the conversation.


3) Move the expiration timer from the ConversationScopeContainer to 
the ConversationManager.


If different Conversations can have different expiration timers then the 
timer needs to be on the Conversation object instead of the 
ConversationManager.


4) The ConversationScopeContainer will be registered as listener to 
the ConversationManager. When an active conversation is started, 
expired or ended, the ConversationScopeContainer will be notified.


It might be easier to register the actual instance wrapper wrappering 
the component instance associated with a particular conversation.




5) The ConversationManager maintains the conversations using an 
in-memory Map as the first step. In the future, it can be extended to 
backed by a persistent store.


+1 to use an in-memory map for now.



Thanks,
Raymond

- Original Message - From: "Simon Laws" 
<[EMAIL PROTECTED]>

To: 
Sent: Sunday, September 09, 2007 11:10 AM
Subject: Re: Resetting state of service references at conversation end



Hi Raymond

some comments below...

Simon

On 9/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I have been thinking of this problem as well. It's not realistic to 
search
for all CallableReferences because it can be dynamically created 
too. We



Agreed. You would have to have registered them somewhere first. This 
is what

happens in the case of the conversation scope container currently.

probably need to use a listener pattern to have all the Conversation 
objects

listen on the events of expiration or end of the conversation and reset
the
state based on the event. Another way is to have a pointer to the



This would rely on having the conversation object register with 
something
that is able to broadcast these events. Where would be a sensible 
place to

put this event broadcasting function. Do we have an internal eventing
feature? Scope container?

ScopeContainer in the ConversationImpl object and query the state of the

conversation before it's used.



This wo

Re: IntentAttachPoint

[Jean-Sebastien Delfino]

Greg Dritschler wrote:

I have a question about changes that were made in revision 566649.  This
revision changed the assembly model object interfaces so that they don't
extend IntentAttachPoint.  The assembly model implementations now extend
IntentAttachPoint.  As a consequence any code that wants to reference the
intents needs to check if the implementation object is an instance of
IntentAttachPoint and then cast it.  Why was this done?  I'm not saying it's
right or wrong, I just want to know the point of the change.  It seems to
allow assembly model objects (implementations, bindings) to be created which
don't support intents.  Is that a good thing?

Greg

  


I think it's a good thing :) The idea is as follows:

- Some bindings and implementation types will not support policies. For 
example only some binding types will support confidentiality, only some 
implementation types will support transactions. The policy framework 
spec defines how to describe binding types and implementation types and 
the policies that can be applied to them in definitions.xml. It's easy 
to imagine that some binding or implementation types will not support 
any policy.


- We can make the development of binding or implementation extensions 
which don't support any policy simpler by not requiring them to 
implement IntentAttachPoint and PolicySetAttachPoint.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3

[ant elder (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ant elder reassigned TUSCANY-1561:
--

Assignee: ant elder

> Move up from Axis2 1.2 to 1.3
> -
>
> Key: TUSCANY-1561
> URL: https://issues.apache.org/jira/browse/TUSCANY-1561
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Axis Binding Extension, Java SCA Data Binding 
> Runtime
>Affects Versions: Java-SCA-0.91
>Reporter: ant elder
>Assignee: ant elder
> Fix For: Java-SCA-1.0
>
> Attachments: 1561-java.diff, 1561.patch
>
>
> Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom.

-- 
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-1683) AXIS data binding can not process array Type response

[wenchu (JIRA)]

AXIS data binding can not process array Type response
-

 Key: TUSCANY-1683
 URL: https://issues.apache.org/jira/browse/TUSCANY-1683
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-0.99
 Environment: windows jboss axis2
Reporter: wenchu


I want to publish a service, it interface describe below:
public interface UDBService{public User[] getUsersByCompanyId(String 
companyId);}

I use  java2wsdl tools of axis2 to generate wsdl, it describe below:


   
  
   



but i find org.apache.tuscany.sca.databinding.javabeans.JavaBean2XMLTransformer 
can run correct  and it check array type,change it correct. when client receive 
the xml, and 
org.apache.tuscany.sca.databinding.javabeans.XML2JavaBeanTransformer transform 
error.

the reason as below:
1.not to check it's type.
2.to create object use " L javaInstance = javaType.newInstance()  " it will 
throw exception ,because jdk not support use this method to create array type 
instance. It is line 82.

i  check the javaType and do anther process,modify code as below:

// mod by wenchu.cenwc array type process
if (javaType.isArray())
{
L javaInstance = 
(L)Array.newInstance(Class.forName(javaType.getComponentType().getName())
, childElements.size());

for (int count = 0; count < childElements.size(); 
++count) 
{
Object node = 
createJavaObject(childElements.get(count)

,Class.forName(javaType.getComponentType().getName()),context);

Array.set(javaInstance, count, node);
}

return javaInstance;
}
else
{

L javaInstance = javaType.newInstance();
..
return javaInstance;
}



-- 
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: Including the XQuery sample in the next release?

[Vasil Vasilev]

Hi Jean,

I didn't do it yet. I was just waiting to see if there will be some positive 
progress with using Saxon 8.9. However it appears that currently there is no, 
so I will try it.

Bye Vasil


 > Оригинално писмо 
 >От:  Jean-Sebastien Delfino <[EMAIL PROTECTED]>
 >Относно: Re: Including the XQuery sample in the next release?
 >До: tuscany-dev@ws.apache.org
 >Изпратено на: Вторник, 2007, Септември 11 11:24:58 EEST
 >--
 >
 >Jean-Sebastien Delfino wrote:
 >> Vasil Vasilev wrote:
 >>> Hi,
 >>>
 >>> Isn't in the official repository some older version of Saxon. May be 
 >>> we could try to run the prototype with this older version.
 >>>
 >>> Bye, Vasil
 >>>
 >>>
 >>>   
 >>
 >> If the Saxon project really doesn't want to publish newer JARs then I 
 >> guess we're going to have to use the 8.7 version already on ibiblio.org.
 >>
 >> In the longer term, this also gives us a good opportunity to think 
 >> about making XQuery processor implementations pluggable, as you 
 >> already suggested :)
 >>
 >
 >Hi Vasil,
 >
 >Did you manage to backport and run the XQuery implementation code on 
 >Saxon 8.7? or are there any issues with 8.7 and we should try to see 
 >what we can do to get 8.9 published in a Maven repos?
 >
 >Thanks
 >
 >-- 
 >Jean-Sebastien
 >
 >
 >-
 >To unsubscribe, e-mail: [EMAIL PROTECTED]
 >For additional commands, e-mail: [EMAIL PROTECTED]
 >
 >

-
Всички учебници и помагала - отстъпка+доставка WWW.MOBILIS.BG

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (TUSCANY-1561) Move up from Axis2 1.2 to 1.3

[ant elder (JIRA)]

[ 
https://issues.apache.org/jira/browse/TUSCANY-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526409
 ] 

ant elder commented on TUSCANY-1561:


"I am running into a few test errors with this patch" A "few" !

> Move up from Axis2 1.2 to 1.3
> -
>
> Key: TUSCANY-1561
> URL: https://issues.apache.org/jira/browse/TUSCANY-1561
> Project: Tuscany
>  Issue Type: Improvement
>  Components: Java SCA Axis Binding Extension, Java SCA Data Binding 
> Runtime
>Affects Versions: Java-SCA-0.91
>Reporter: ant elder
>Assignee: ant elder
> Fix For: Java-SCA-1.0
>
> Attachments: 1561-java.diff, 1561.patch
>
>
> Move up from Axis2 1.2 to 1.3 and associated sub-components like Axiom.

-- 
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-1673 and SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?

[kelvin goodson]

Luciano,

  can you confirm in the JIRA whether the updated fix is good? I'll
keep an eye on this thread to see how your plans develop,  and what
that might mean for SDO release plans.

Kelvin.

On 10/09/2007, Luciano Resende <[EMAIL PROTECTED]> wrote:
> We have found an issue on the SDO Tools, described in JIRA-1673 [1]
> that is affecting the proper generation of java interfaces from a
> given wsdl.
>
> What's the plan to get this fix, when available, in SCA 1.0 release ?
> This might require a new SDO release ?
>
> [1] http://issues.apache.org/jira/browse/TUSCANY-1673
>
> On 9/3/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > Great, so looks like we would need a DAS release compatible with SDO
> > 1.0 in order to include any SCA/DAS integration in the SCA 1.0
> > release. I'll try to get that done, by cutting a branch and working on
> > a DAS release sometime this week. Please let me know if there is any
> > changes in plan.
> >
> > On 8/28/07, kelvin goodson <[EMAIL PROTECTED]> wrote:
> > > There are no plans in place yet for the next SDO release.
> > > 1.0-incubating would seem the obvious choice.
> > >
> > > Kelvin.
> > >
> > > On 28/08/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > > That would be my guess unless there's a newer SDO release by then but 
> > > > i've
> > > > not seen any mention of that in the SDO emails.
> > > >
> > > >  ...ant
> > > >
> > > > On 8/27/07, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > What are you guys thinking about SDO requirements for SCA 1.0 release
> > > > > ? SDO 1.0-incubating ?
> > > > >
> > > > > -- Forwarded message --
> > > > > From: Simon Laws <[EMAIL PROTECTED]>
> > > > > Date: Aug 27, 2007 2:58 AM
> > > > > Subject: Re: SCA 1.0 release (was Re: Release management for next
> > > > > release, was: SCA 0.92 release?
> > > > > To: tuscany-dev@ws.apache.org, [EMAIL PROTECTED]
> > > > >
> > > > >
> > > > > On 8/27/07, ant elder <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > On 8/9/07, Venkata Krishnan <[EMAIL PROTECTED] > wrote:
> > > > > >
> > > > > > 
> > > > > >
> > > > > > - Post 0.95, maybe a couple of weeks after the release, we'd cut
> > > > > > > another branch and head with that for 1.0 release.   Being a 1.0
> > > > > > > release, we prob. need a branch early as that so that we can whet 
> > > > > > > the
> > > > > > > things we are targetting for the release.
> > > > > >
> > > > > >
> > > > > > This seems like a really good idea to me. The 0.99 release has again
> > > > > shown
> > > > > > that it always takes at least a couple of RCs to discover and 
> > > > > > resolve
> > > > > > regressions caused by last minute changes and to polish up the 
> > > > > > samples,
> > > > > > and
> > > > > > for 1.0 we're all likely to be a bit more pedantic about readme and
> > > > > sample
> > > > > > problems. How about aiming for a 1.0 branch and RC1 around the 14th 
> > > > > > of
> > > > > > September? That gives 3 weeks from now for getting things ready and 
> > > > > > then
> > > > > > two
> > > > > > weeks which should enough for 2 or 3 RCs and voting and still get a 
> > > > > > 1.0in
> > > > > > September.
> > > > > >
> > > > > > I've created a 1.0 JIRA version and started moving into there JIRAs 
> > > > > > i'd
> > > > > > like
> > > > > > to try to get done for 1.0 :
> > > > > >
> > > > > >
> > > > > http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310210&fixfor=12312698
> > > > > >
> > > > > >
> > > > > > One thing that would be good to do now while they're fresh in our 
> > > > > > minds
> > > > > is
> > > > > > for people to commit fixes to trunk for all the sample and readme 
> > > > > > issues
> > > > > > they reported in the 0.99 review so they don't get forgotten till
> > > > > > 1.0review.
> > > > > >
> > > > > >...ant
> > > > > >
> > > > > +1 from me. I think we are going to need the extra time to fix the 
> > > > > many
> > > > > small things we found this time round.
> > > > >
> > > > > Simon
> > > > >
> > > > >
> > > > > --
> > > > > 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]
> > > > >
> > > > >
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende
> > http://lresende.blogspot.com/
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>
> 

Re: Issue with dynamic creation of NotificationReferenceBindingProvider

[Ignacio Silva-Lepe]

This sounds quite reasonable. I am all for not complicating
the SPI if we don't have to.
But this does mean that we can't just revert back to the
previous state of statically created references, as the lazy
creation of invocation chains seems to be something we
did not have.
Let me know if you or Raymond would like to take care of
this or I should go ahead and do it.
If I understand you correctly, the notification binding should
work without any further chnage once your suggestion is
in place.

On 9/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Comments inline.
>
> [snip]
> Raymond Feng wrote:
> >
> >>
> >> What do you mean by "a reference can be dynamically created"? can you
> >> please describe the scenario you have in mind?
> >>
> >
> > There are a few cases:
> > 1) SCADomain.getService() will create self reference
> > 2) ComponentContext.createSelfReference()
> > 3) ComponentContext.getService() (if the business interface is not the
> > same as the reference)
> > 4) Rebind a reference to a target
> >
>
> OK I see now. So, we have two cases:
>
> (A) a reference is statically declared on a component
> ==> The binding provider(s) for the reference binding(s) should be
> started when the component is started. The actual sequence is:
> 1. the component is created
> 2. the reference is created
> 3. the reference is started
> 4. the component is started
>
> (B) a "floating" reference is created
> ==> The binding provider(s) for the reference binding(s) should be
> started just after the reference is created.
> 1. the reference is created
> 2. the reference is started
>
> Invocation chains can be created whenever we want (lazily on first
> invocation if we wish) as they have no lifecycle attached to them
>
> I think that this resolves the binding.notification issue (getting
> started early), while accommodating for dynamically created references,
> and without complicating the SPIs with another option.
>
> At this point and for our upcoming 1.0 release I'd like to apply the
> Ockam's Razor principle [1] to our SPIs and keep them as slim and simple
> as possible :)
>
> [1] http://en.wikipedia.org/wiki/Occam%27s_razor
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

[jira] Created: (TUSCANY-1684) Web Service binding incompatibility when referencing a WebService hosted on JBoss

[JIRA]

Web Service binding incompatibility when referencing a WebService hosted on 
JBoss
-

 Key: TUSCANY-1684
 URL: https://issues.apache.org/jira/browse/TUSCANY-1684
 Project: Tuscany
  Issue Type: Bug
  Components: Java SCA Axis Binding Extension
Affects Versions: Java-SCA-0.99
 Environment: Windows XP, Tuscany 0.99 downloaded the 10th Sept. 2007, 
JBoss-5.0.0.Beta2
Reporter: Marco Dalcó


Deploy a simple WebService on JBoss. Access it using a tool like SoapUI. It 
works fine. Access it from Tuscany, with a  containing http://theUri";>. It fails.

Comparing the messages they send, there are two main differences:
 
1) The namespace of the method invoked. In the Tuscany message it has an 
additional "xsd" at the end
2) The name of the parameter of the method. It is "arg0" with SoapUI and 
"param0" with Tuscany
 
It could be a problem of library versions, WebService specifications, a bug or 
whatever.
I tried the "requires", "wsdli:wsdlLocation", "wsdlElement" in many 
combinations, with no success.

What is this incompatibility due to?

-- 
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-1684) Web Service binding incompatibility when referencing a WebService hosted on JBoss

[JIRA]

 [ 
https://issues.apache.org/jira/browse/TUSCANY-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marco Dalcó updated TUSCANY-1684:
-

Attachment: ReferenceToJBOSSWSTestCase.zip

This test case builds a jar file to be deployed in JBoss and another one to run 
the test.
Use with Tuscany 0.99.
1) set the JBOSS_HOME environment variable to the root directory of your JBoss 
5.0.0.Beta2 installation.
2) Unzip the attachment in the tuscany-sca-0.99-incubating\demos directory.
3) Run "ant compile" from within the project directory.
4) Deploy the target/jboss-webservice.jar file in JBoss (copy it to the 
%JBOSS_HOME%\server\default\deploy directory).
5) Start JBoss
6) When JBoss has completely started, test that the WebService is correctly 
deployed, opening the URL http://localhost:8080/jbossws/services: there should 
be a link to the WebService WSDL, like this: 
http://:8080/jboss-webservice/WebServiceImpl?wsdl
7) Run "ant run"

After a few seconds the command should fail and in the [java] ant logs you 
should see an error like this:
 [java] Caused by: org.apache.axis2.AxisFault: Endpoint 
{http://ejb.sca_ws_reference.ubiquity.net/}WebServiceImplPort does not contain 
operation meta data for: 
{http://ejb.sca_ws_reference.ubiquity.net/xsd}getWelcome

In order to use a proxy logging tool like Trivial Proxy, run and set the tool 
to redirecet communications from the port 18080 to the 8080, change the port 
number from 8080 to 18080 in the resources\sca\application.composite file of 
the project and run "ant run" again.

> Web Service binding incompatibility when referencing a WebService hosted on 
> JBoss
> -
>
> Key: TUSCANY-1684
> URL: https://issues.apache.org/jira/browse/TUSCANY-1684
> Project: Tuscany
>  Issue Type: Bug
>  Components: Java SCA Axis Binding Extension
>Affects Versions: Java-SCA-0.99
> Environment: Windows XP, Tuscany 0.99 downloaded the 10th Sept. 2007, 
> JBoss-5.0.0.Beta2
>Reporter: Marco Dalcó
> Attachments: ReferenceToJBOSSWSTestCase.zip
>
>
> Deploy a simple WebService on JBoss. Access it using a tool like SoapUI. It 
> works fine. Access it from Tuscany, with a  containing  uri="http://theUri";>. It fails.
> Comparing the messages they send, there are two main differences:
>  
> 1) The namespace of the method invoked. In the Tuscany message it has an 
> additional "xsd" at the end
> 2) The name of the parameter of the method. It is "arg0" with SoapUI and 
> "param0" with Tuscany
>  
> It could be a problem of library versions, WebService specifications, a bug 
> or whatever.
> I tried the "requires", "wsdli:wsdlLocation", "wsdlElement" in many 
> combinations, with no success.
> What is this incompatibility due to?

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

Incompatibility between Tuscany and JBoss WebServices

[Marco Dalco]

Raised a JIRA:

 

https://issues.apache.org/jira/browse/TUSCANY-1684




Information contained in this e-mail and any attachments are intended for the 
use of the addressee only, and may contain confidential information of Ubiquity 
Software Corporation. All unauthorized use, disclosure or distribution is 
strictly prohibited.  If you are not the addressee, please notify the sender 
immediately and destroy all copies of this email. Ubiquity Software Corporation 
plc, a company registered under the laws of England and Wales, Registration 
2719723, registered offices at Eastern Business Park, Building 3, Wern Fawr 
Lane, St. Mellons, Cardiff CF3 5EA, Wales, United Kingdom.

Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)

[Simon Nash]

Thanks for pointing out this issue.  I think we're OK with just
using ConversationID as the correlator as long as we make the
following assumptions:

 1. The correlation from ConversationID to callback object is done
on a per-reference basis.
 2. The callback goes to the callback object that is set into the
reference at the time the callback is made, not at the time
the forward call is made.

Consider the following code:

  myRef = componentContext.getServiceReference(convInterface, refName);
  myRef.setCallback(callback1);
  myRef.getService().startConversation();
  myRef.setCallback(callback2);
  myRef.getService().continueConversation();
  myRef.setCallback(callback3);

With the assumptions listed above, the callbacks from startConversation()
and continueConversation() would go to callback3 (the current value)
instead of callback1 and callback2 respectively (the values at the time
of the forward calls).  I don't see anything in the spec that says that
this is not correct.

Does this take care of the cases you had in mind?

  Simon

Raymond Feng wrote:


+1 on the proposal. There is one more thing to add.

For the case that the callback object is not a ServiceReference, we 
don't flow it in the Message, but we still need to correlate the 
callback to this object so that the callback can be routed to the right 
callback object. ConversationID alone is good enough, because
we can use different callback objects in the same conversation. I 
suggest that we add a "CallbackObjectID" to reference parameter under 
the CallbackReference. The CallbackObjectID can be the system hash code 
of the callback object. The ConversationID + CallbackObjectID will be 
the key for the correlation.


Do you agree?

Thanks,
Raymond

- Original Message - From: "Jean-Sebastien Delfino" 
<[EMAIL PROTECTED]>

To: 
Sent: Monday, September 10, 2007 3:43 PM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)




Comments inline.

[snip]
Simon Nash wrote:

I agree that we need a conclusion.  I believe the detailed proposal 
below
supports all the SCA semantics and I'd like to propose that we go 
with it

for Tuscany 1.0.

Any comments, questions, agreement, or disagreement?

  Simon



I was initially thinking that the Callback EPR should be a separate 
header outside of the To EPR but the code snippet that you put 
together to simulate the SCA built-in callback (at the bottom of that 
email) convinced me that I was wrong about it :)


So I'm +1 with your proposal in [1]:

Request message

 
   ...URI of the service being invoked...
   
 callback-A01
 conversation-006
 
   
 ...URI of the service for the 
callback...

 
 
 
  


Callback message:

 
   ...URI of the service for the callback...
   
 callback-A01
 conversation-006
   
 


In plain text:
- CallbackID flows as a reference parameter of the "To" EPR
- ConversationID flows as a reference parameter of the "To" EPR
- CallbackReference is a well formed EPR and flows as a reference 
parameter of the "To" EPR


I think that we should propose this mapping to the OASIS SCA Bindings 
workgroup. Different implementations of SCA should follow the same 
mapping if we want them to interoperate over Web Services for example.


[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html


[snip]



Yes, I'm proposing what I said in [1] with a 

reference parameter under the wsa:To stateful EPR.  Looking at this 
again,

it could be slightly improved to eliminate the 
and  within , giving:


   
  ...URI of the service being 
invoked...

  
  callback-A01

conversation-006
  
 ...URI of the service for the callback...
  
  
   


This requires the  to be "fluffed up" into
a  when the callback is sent, with the
 and  as its reference
parameters:


   
  ...URI of the service for the 
callback...

  
  callback-A01

conversation-006
  
   


  Simon



I'm not keen on doing that. I'd prefer to stick to your initial 
proposal which seems cleaner to me, using the same standard form to 
represent the CallbackReference EPR in the request message and the To 
EPR in the callback message.






 @Service(Client.class)
 class Client {
ComponentContext componentContext;
Writer writer;

write(inputData) {
   target = 
componentContext.getServiceReference(Writer.class, "writer");

   self = componentContext.createSelfReference();
   id = new UUID();
   target.setCallbackID(id);
   self.setCallbackID(id);
   target.setCallback(self);
   target.getService().asyncWrite(target, inputData);
}

written(myReference) {
   // data  has been written
}
 }

 @Service(Writer.class)
 class Writer {

@OneWay
asyncWrite(myReference, inputData) {
   // actually write the data

   clientReference = myReference.getCallback();
   clientReference.getService()

Re: Resetting state of service references at conversation end

[Simon Laws]

On 9/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> I'm overall +1 with this proposal, with some minor changes described in
> comments inline.
>
> Raymond Feng wrote:
> > Hi,
> >
> > As we agreed, the conversation id alone is not sufficient to deal with
> > conversations. We need to maintain the state of the conversations
> > (STARTED, ENDED or EXPIRED).
>
> Right, if I understand correctly we need to keep the state of a
> conversation in a central place in a Tuscany runtime that all
> participants can point to, allowing one to end the conversation, and the
> other conversation participants to see that it has ended.


I would go further than  this to say, if we follow the words of the spec, we
should keep the state of a conversation in a central place in a domain. At
least in the very specific cases where there is a 3rd party involved in the
conversation. However a sentral place in a node is a good place to start.

>
> > I propose that we do the following:
> >
> > 1) Define a ConversationManager like:
> >
> > public interface ConversationManager() {
> >String start(String conversationID);  // If the conversationID is
> > null, the system will generate one. Returns the conversation ID
> Conversation startConversation(Object conversationID) as the
> conversation ID is not always a String.
>
> Change start to startConversation to make clear that it's the
> conversation that you're starting and not the ConversationManager.
>
> Also I think it's better to return the Conversation object (see below
> for its contents).


Why don't we register a Conversation object with a ConversationManager and
do away with getConversationState

>void end(String conversationID);  // Ends the conversation
>
> void endConversation(Conversation conversation)
>
> Don't you need another method to make a conversation expire?
>
> >ConversationState getConversationState(String conversationID); //
> > Get the state of the conversation
>
> Conversation getConversation(Object conversationID)


+1

>void register(ConversationListener listener); // Register a listener
> >void unregister(ConversationListener listener); // Remove a listener
>
> Let's try to be consistent with other listener interfaces:
> addListener(ConversationListener listener)
> removeListener(ConversationListener listener)
>
> Also, these methods should be on the Conversation object described below
> I think.

> }
> >
> > public interface ConversationListener() {
> >void conversationStarted(String conversationID);
> >void conversationEnded(String conversationID);
> >void conversationExpired(String conversationID);
> > }
>
> Pass Conversation conversation instead of String conversationID.
>
> If the methods are on the Conversation object instead of the
> ConversationManager they can be simpler I think:
> public interface ConversationListener() {
>void conversationStarted();
>void conversationEnded();
>void conversationExpired();
> }


>
> > public enum ConversationState {
> >STARTED, ENDED, EXPIRED
> > }
>
> class Conversation {
>   ConversationState state;
>   Object conversationID;
> }
>
> Having this class allows you to evolve it over time, does not rely on
> the fact that conversations are stored in a map, and also IMO better
> represents what you'll store in persistent storage in the future.
>
> Do we we need an expiry time field here as well?
>
> >
> > 2) The proxy or callable references will only keep the conversation
> > ID. Whenever the Conversation object is referenced or we need to
> > perform any actions to a conversation, we use the ID to look up the
> > state of the conversation.
> >
> > 3) Move the expiration timer from the ConversationScopeContainer to
> > the ConversationManager.
>
> If different Conversations can have different expiration timers then the
> timer needs to be on the Conversation object instead of the
> ConversationManager.
> >
> > 4) The ConversationScopeContainer will be registered as listener to
> > the ConversationManager. When an active conversation is started,
> > expired or ended, the ConversationScopeContainer will be notified.
>
> It might be easier to register the actual instance wrapper wrappering
> the component instance associated with a particular conversation.


An instance wrapped could be registered as a listener with multiple
conversations.

>
> > 5) The ConversationManager maintains the conversations using an
> > in-memory Map as the first step. In the future, it can be extended to
> > backed by a persistent store.
>
> +1 to use an in-memory map for now.
>
> >
> > Thanks,
> > Raymond
> >
> > - Original Message - From: "Simon Laws"
> > <[EMAIL PROTECTED]>
> > To: 
> > Sent: Sunday, September 09, 2007 11:10 AM
> > Subject: Re: Resetting state of service references at conversation end
> >
> >
> >> Hi Raymond
> >>
> >> some comments below...
> >>
> >> Simon
> >>
> >> On 9/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have been thi

[jira] Created: (TUSCANY-1685) SDOXSDECoreBuilder.validAliasName(XSDTypeDefinition) does not mangle dashes in typeNames to underscores

[Ron Gavlin (JIRA)]

SDOXSDECoreBuilder.validAliasName(XSDTypeDefinition) does not mangle dashes in 
typeNames to underscores
---

 Key: TUSCANY-1685
 URL: https://issues.apache.org/jira/browse/TUSCANY-1685
 Project: Tuscany
  Issue Type: Bug
  Components: Java SDO Implementation
Affects Versions: Java-SDO-1.0
Reporter: Ron Gavlin
Priority: Critical


I have the following complex type in a schema:







When I use XSD2JavaGenerator to code-generate classes for this schema, an 
invalidly named Bogus-1.java class is generated. The class name should be 
mangled into a valid Java class name, such as Bogus_1.java. EMF provides this 
behavior in its NameMangler which Tuscany currently disables.



-- 
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: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)

[Raymond Feng]

Comments inline.

Thanks,
Raymond

- Original Message - 
From: "Simon Nash" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, September 11, 2007 7:47 AM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)




Thanks for pointing out this issue.  I think we're OK with just
using ConversationID as the correlator as long as we make the
following assumptions:

 1. The correlation from ConversationID to callback object is done
on a per-reference basis.


Are you assuming for the lifecylce of a conversation, there is only one 
effective callback object for a given service reference? Even so, we still 
need to do some correlations (using the callback endpoint URI as the key?) 
to relate a callback to the given service reference, right?



 2. The callback goes to the callback object that is set into the
reference at the time the callback is made, not at the time
the forward call is made.

Consider the following code:

  myRef = componentContext.getServiceReference(convInterface, refName);
  myRef.setCallback(callback1);
  myRef.getService().startConversation();
  myRef.setCallback(callback2);
  myRef.getService().continueConversation();
  myRef.setCallback(callback3);



Are you saying if the myRef.setCallback() is called for multiple times, the 
effective callback object will override the previous one? If so and if 
startConversation() and contineConversation() are one-way async operations, 
the result is unpredictable.



With the assumptions listed above, the callbacks from startConversation()
and continueConversation() would go to callback3 (the current value)
instead of callback1 and callback2 respectively (the values at the time
of the forward calls).  I don't see anything in the spec that says that
this is not correct.


Assuming both the forward call and callback are synchronous, if the callback 
happens in the startConversation() method of the target service, then it 
will go to callback1, right? In this case, the setCallback(callback2) hasn't 
even been called.




Does this take care of the cases you had in mind?

  Simon

Raymond Feng wrote:


+1 on the proposal. There is one more thing to add.

For the case that the callback object is not a ServiceReference, we don't 
flow it in the Message, but we still need to correlate the callback to 
this object so that the callback can be routed to the right callback 
object. ConversationID alone is good enough, because
we can use different callback objects in the same conversation. I suggest 
that we add a "CallbackObjectID" to reference parameter under the 
CallbackReference. The CallbackObjectID can be the system hash code of 
the callback object. The ConversationID + CallbackObjectID will be the 
key for the correlation.


Do you agree?

Thanks,
Raymond

- Original Message - From: "Jean-Sebastien Delfino" 
<[EMAIL PROTECTED]>

To: 
Sent: Monday, September 10, 2007 3:43 PM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)




Comments inline.

[snip]
Simon Nash wrote:

I agree that we need a conclusion.  I believe the detailed proposal 
below
supports all the SCA semantics and I'd like to propose that we go with 
it

for Tuscany 1.0.

Any comments, questions, agreement, or disagreement?

  Simon



I was initially thinking that the Callback EPR should be a separate 
header outside of the To EPR but the code snippet that you put together 
to simulate the SCA built-in callback (at the bottom of that email) 
convinced me that I was wrong about it :)


So I'm +1 with your proposal in [1]:

Request message

 
   ...URI of the service being invoked...
   
 callback-A01
 conversation-006
 
   
 ...URI of the service for the 
callback...

 
 
 
  


Callback message:

 
   ...URI of the service for the callback...
   
 callback-A01
 conversation-006
   
 


In plain text:
- CallbackID flows as a reference parameter of the "To" EPR
- ConversationID flows as a reference parameter of the "To" EPR
- CallbackReference is a well formed EPR and flows as a reference 
parameter of the "To" EPR


I think that we should propose this mapping to the OASIS SCA Bindings 
workgroup. Different implementations of SCA should follow the same 
mapping if we want them to interoperate over Web Services for example.


[1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg22923.html


[snip]



Yes, I'm proposing what I said in [1] with a 

reference parameter under the wsa:To stateful EPR.  Looking at this 
again,
it could be slightly improved to eliminate the 


and  within , giving:


   
  ...URI of the service being 
invoked...

  
  callback-A01

conversation-006
  
 ...URI of the service for the callback...
  
  
   


This requires the  to be "fluffed up" into
a  when the callback is sent, with the
 and  as its reference
parameters:


   
  ...URI of the service for t

Re: Resetting state of service references at conversation end

[Mark Combellack]

Raymond Feng <[EMAIL PROTECTED]> writes:

> 
> Hi,
> 
> As we agreed, the conversation id alone is not sufficient to deal with 
> conversations. We need to maintain the state of the conversations (STARTED, 
> ENDED or EXPIRED).
> 
> I propose that we do the following:
> 
> 1) Define a ConversationManager like:
> 
> public interface ConversationManager() {
> String start(String conversationID);  // If the conversationID is null, 
> the system will generate one. Returns the conversation ID
> void end(String conversationID);  // Ends the conversation
> ConversationState getConversationState(String conversationID); // Get 
> the state of the conversation
> void register(ConversationListener listener); // Register a listener
> void unregister(ConversationListener listener); // Remove a listener
> }
> 
> public interface ConversationListener() {
> void conversationStarted(String conversationID);
> void conversationEnded(String conversationID);
> void conversationExpired(String conversationID);
> }
> 
> public enum ConversationState {
> STARTED, ENDED, EXPIRED
> }
> 

Hi,

One comment on the above API, conversation IDs are not always Strings.

The SCA Specification allows a user to specify a conversation ID as an
object.

For more information, see:

https://issues.apache.org/jira/browse/TUSCANY-1522

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Trouble with Maven including rampart.mar as dependency

[Venkata Krishnan]

Hi Deepal, thanks for responding.  Did you mean moving to 1.3 would resolve
this maven related problem?  Anyways, I have moved up to 1.3.  But that does
not solve this problem.

- Venkat

On 9/11/07, Deepal jayasinghe <[EMAIL PROTECTED]> wrote:
>
> Venkata Krishnan wrote:
> > Hi,
> >
> > I am trying use rampart for security support on the ws-binding in
> > Apache Tuscany Java SCA.  I included the rampart.mar as dependency in
> > the axis2 ws binding pom file (
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-ws-axis2/pom.xml
> )
> > as follows : -
> >
> > 
> > org.apache.rampart
> > rampart
> > 1.2
> > mar
> > runtime
> > 
> >
> > While Maven successfully downloads and installs rampart.mar it seems
> > like its not including it in the build classpath as a result of which
> > I get a 'trying to engage an unavailable module' exception.  Am I
> > missing something here?  Could somebody help with hints ?  Thanks.
> >
> > PS : When I imported the project into eclipse I found that the
> > .classpath that maven generates does not contain the .mar file.
> > Including this explicitly runs everything cleanly within eclipse.
> > Hence my suspicion on Maven ever doing anything with the .mar file.
> >
> > Thanks
> > - Venkat
> Please use Rampart 1.3 instead of 1.2.
>
> Thanks
> Deepal
>
> --
> Thanks,
> Deepal
> 
> "The highest tower is built one brick at a time"
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Resetting state of service references at conversation end

[Raymond Feng]

OK. I'll add the interfaces first for review. Should they go to the 
core-spi?


Thanks,
Raymond

- Original Message - 
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, September 11, 2007 2:02 AM
Subject: Re: Resetting state of service references at conversation end


I'm overall +1 with this proposal, with some minor changes described in 
comments inline.


Raymond Feng wrote:

Hi,

As we agreed, the conversation id alone is not sufficient to deal with 
conversations. We need to maintain the state of the conversations 
(STARTED, ENDED or EXPIRED).


Right, if I understand correctly we need to keep the state of a 
conversation in a central place in a Tuscany runtime that all participants 
can point to, allowing one to end the conversation, and the other 
conversation participants to see that it has ended.




I propose that we do the following:

1) Define a ConversationManager like:

public interface ConversationManager() {
   String start(String conversationID);  // If the conversationID is 
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the conversation 
ID is not always a String.


Change start to startConversation to make clear that it's the conversation 
that you're starting and not the ConversationManager.


Also I think it's better to return the Conversation object (see below for 
its contents).



   void end(String conversationID);  // Ends the conversation


void endConversation(Conversation conversation)

Don't you need another method to make a conversation expire?

   ConversationState getConversationState(String conversationID); // Get 
the state of the conversation


Conversation getConversation(Object conversationID)


   void register(ConversationListener listener); // Register a listener
   void unregister(ConversationListener listener); // Remove a listener


Let's try to be consistent with other listener interfaces:
addListener(ConversationListener listener)
removeListener(ConversationListener listener)

Also, these methods should be on the Conversation object described below I 
think.



}

public interface ConversationListener() {
   void conversationStarted(String conversationID);
   void conversationEnded(String conversationID);
   void conversationExpired(String conversationID);
}


Pass Conversation conversation instead of String conversationID.

If the methods are on the Conversation object instead of the 
ConversationManager they can be simpler I think:

public interface ConversationListener() {
  void conversationStarted();
  void conversationEnded();
  void conversationExpired();
}




public enum ConversationState {
   STARTED, ENDED, EXPIRED
}


class Conversation {
 ConversationState state;
 Object conversationID;
}

Having this class allows you to evolve it over time, does not rely on the 
fact that conversations are stored in a map, and also IMO better 
represents what you'll store in persistent storage in the future.


Do we we need an expiry time field here as well?



2) The proxy or callable references will only keep the conversation ID. 
Whenever the Conversation object is referenced or we need to perform any 
actions to a conversation, we use the ID to look up the state of the 
conversation.


3) Move the expiration timer from the ConversationScopeContainer to the 
ConversationManager.


If different Conversations can have different expiration timers then the 
timer needs to be on the Conversation object instead of the 
ConversationManager.


4) The ConversationScopeContainer will be registered as listener to the 
ConversationManager. When an active conversation is started, expired or 
ended, the ConversationScopeContainer will be notified.


It might be easier to register the actual instance wrapper wrappering the 
component instance associated with a particular conversation.




5) The ConversationManager maintains the conversations using an in-memory 
Map as the first step. In the future, it can be extended to backed by a 
persistent store.


+1 to use an in-memory map for now.



Thanks,
Raymond

- Original Message - From: "Simon Laws" 
<[EMAIL PROTECTED]>

To: 
Sent: Sunday, September 09, 2007 11:10 AM
Subject: Re: Resetting state of service references at conversation end



Hi Raymond

some comments below...

Simon

On 9/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I have been thinking of this problem as well. It's not realistic to 
search
for all CallableReferences because it can be dynamically created too. 
We



Agreed. You would have to have registered them somewhere first. This is 
what

happens in the case of the conversation scope container currently.

probably need to use a listener pattern to have all the Conversation 
objects

listen on the events of expiration or end of the conversation and reset
the
state based on the event. Another way is to have a pointer to the



This would rely on having the conversation object register with 

How to handle business exceptions not easily serializable to XML

[Scott Kurz]

Say I wanted to have a remotable Java interface with a method like:

 int myMethod() throws java.sql.SQLException;

Should I be able to throw this exception, say, across the web service
binding?

I don't see why not.JAX-WS Sec 3.7 describes how to build a fault bean
out of an exception like SQLException which doesn't conform to the pattern
in JAX-WS Sec 2.5. A tool like wsgen should be able to generate a WSDL
with a corresponding fault element, typed by the default mapping obtained by
viewing SQLException as a JavaBean (Sec 3.7) per JAXB.

(For a complicated data type the default JAXB mapping isn't enough without
annotations, but for simpler examples it might be OK.)

Do we view this as a valid remote interface?   I'm not asking whether it
works today.. just whether it seems like it should work.

Scott

Re: Resetting state of service references at conversation end

[Jean-Sebastien Delfino]

More comments inline.

[snip]
Simon Laws wrote:



Right, if I understand correctly we need to keep the state of a
conversation in a central place in a Tuscany runtime that all
participants can point to, allowing one to end the conversation, and the
other conversation participants to see that it has ended.




I would go further than  this to say, if we follow the words of the spec, we
should keep the state of a conversation in a central place in a domain. At
least in the very specific cases where there is a 3rd party involved in the
conversation. However a sentral place in a node is a good place to start.

  


+1, a central place in a node is a good place to start :)


I propose that we do the following:

1) Define a ConversationManager like:

public interface ConversationManager() {
   String start(String conversationID);  // If the conversationID is
null, the system will generate one. Returns the conversation ID
  

Conversation startConversation(Object conversationID) as the
conversation ID is not always a String.

Change start to startConversation to make clear that it's the
conversation that you're starting and not the ConversationManager.

Also I think it's better to return the Conversation object (see below
for its contents).




Why don't we register a Conversation object with a ConversationManager and
do away with getConversationState

  

+1

I think it's what I'm proposing. However I think we should distinguish 
org.osoa.sca.Conversation (the API, for Java clients and component 
implementations) and org.apache.tuscany.whatever.Conversation (the SPI 
Conversation object I'm talking about here).



   void end(String conversationID);  // Ends the conversation

void endConversation(Conversation conversation)

Don't you need another method to make a conversation expire?



   ConversationState getConversationState(String conversationID); //
Get the state of the conversation
  

Conversation getConversation(Object conversationID)




+1

  

[snip]


4) The ConversationScopeContainer will be registered as listener to
the ConversationManager. When an active conversation is started,
expired or ended, the ConversationScopeContainer will be notified.
  

It might be easier to register the actual instance wrapper wrappering
the component instance associated with a particular conversation.




An instance wrapped could be registered as a listener with multiple
conversations.

  


Exactly, an instance wrapper will be registered with the conversation 
associated with an incoming call, plus the conversations that were 
started by any outgoing calls through conversational interfaces. So 
you'll register a wrapper with all the conversations that it 
participates in. So we have two choices:
- register with the conversation an object carrying (the instance 
wrapper + the conversation itself) and then we don't need to pass the 
conversation in the listener methods
- or just register the instance wrapper and then the listener methods 
needs to pass the conversation object.



--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JIRA-1673 and SDO dependencies for SCA 1.0 release, was Fwd: SCA 1.0 release (was Re: Release management for next release, was: SCA 0.92 release?

[Jean-Sebastien Delfino]

kelvin goodson wrote:

Luciano,

  can you confirm in the JIRA whether the updated fix is good? I'll
keep an eye on this thread to see how your plans develop,  and what
that might mean for SDO release plans.

Kelvin.

On 10/09/2007, Luciano Resende <[EMAIL PROTECTED]> wrote:
  

We have found an issue on the SDO Tools, described in JIRA-1673 [1]
that is affecting the proper generation of java interfaces from a
given wsdl.

What's the plan to get this fix, when available, in SCA 1.0 release ?
This might require a new SDO release ?

[1] http://issues.apache.org/jira/browse/TUSCANY-1673




I have checked in a workaround for this problem under revision r574423.

We should leverage the SDO fix as soon as it's in an SDO release, but 
the workaround in place in r574423 will allow a Tuscany SCA 1.0 release 
to work with the published SDO 1.0 release.


I can't comment on the SDO fix as I've just looked into the workaround, 
but Luciano probably can.


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Resetting state of service references at conversation end

[Jean-Sebastien Delfino]

Raymond Feng wrote:
OK. I'll add the interfaces first for review. Should they go to the 
core-spi?


Thanks,
Raymond


Only the interfaces actually used by binding and implementation 
extensions should go to core-spi. If not needed by extensions they 
should go to core.




- Original Message - From: "Jean-Sebastien Delfino" 
<[EMAIL PROTECTED]>

To: 
Sent: Tuesday, September 11, 2007 2:02 AM
Subject: Re: Resetting state of service references at conversation end


I'm overall +1 with this proposal, with some minor changes described 
in comments inline.


Raymond Feng wrote:

Hi,

As we agreed, the conversation id alone is not sufficient to deal 
with conversations. We need to maintain the state of the 
conversations (STARTED, ENDED or EXPIRED).


Right, if I understand correctly we need to keep the state of a 
conversation in a central place in a Tuscany runtime that all 
participants can point to, allowing one to end the conversation, and 
the other conversation participants to see that it has ended.




I propose that we do the following:

1) Define a ConversationManager like:

public interface ConversationManager() {
   String start(String conversationID);  // If the conversationID is 
null, the system will generate one. Returns the conversation ID
Conversation startConversation(Object conversationID) as the 
conversation ID is not always a String.


Change start to startConversation to make clear that it's the 
conversation that you're starting and not the ConversationManager.


Also I think it's better to return the Conversation object (see below 
for its contents).



   void end(String conversationID);  // Ends the conversation


void endConversation(Conversation conversation)

Don't you need another method to make a conversation expire?

   ConversationState getConversationState(String conversationID); // 
Get the state of the conversation


Conversation getConversation(Object conversationID)


   void register(ConversationListener listener); // Register a listener
   void unregister(ConversationListener listener); // Remove a listener


Let's try to be consistent with other listener interfaces:
addListener(ConversationListener listener)
removeListener(ConversationListener listener)

Also, these methods should be on the Conversation object described 
below I think.



}

public interface ConversationListener() {
   void conversationStarted(String conversationID);
   void conversationEnded(String conversationID);
   void conversationExpired(String conversationID);
}


Pass Conversation conversation instead of String conversationID.

If the methods are on the Conversation object instead of the 
ConversationManager they can be simpler I think:

public interface ConversationListener() {
  void conversationStarted();
  void conversationEnded();
  void conversationExpired();
}




public enum ConversationState {
   STARTED, ENDED, EXPIRED
}


class Conversation {
 ConversationState state;
 Object conversationID;
}

Having this class allows you to evolve it over time, does not rely on 
the fact that conversations are stored in a map, and also IMO better 
represents what you'll store in persistent storage in the future.


Do we we need an expiry time field here as well?



2) The proxy or callable references will only keep the conversation 
ID. Whenever the Conversation object is referenced or we need to 
perform any actions to a conversation, we use the ID to look up the 
state of the conversation.


3) Move the expiration timer from the ConversationScopeContainer to 
the ConversationManager.


If different Conversations can have different expiration timers then 
the timer needs to be on the Conversation object instead of the 
ConversationManager.


4) The ConversationScopeContainer will be registered as listener to 
the ConversationManager. When an active conversation is started, 
expired or ended, the ConversationScopeContainer will be notified.


It might be easier to register the actual instance wrapper wrappering 
the component instance associated with a particular conversation.




5) The ConversationManager maintains the conversations using an 
in-memory Map as the first step. In the future, it can be extended 
to backed by a persistent store.


+1 to use an in-memory map for now.



Thanks,
Raymond

- Original Message - From: "Simon Laws" 
<[EMAIL PROTECTED]>

To: 
Sent: Sunday, September 09, 2007 11:10 AM
Subject: Re: Resetting state of service references at conversation end



Hi Raymond

some comments below...

Simon

On 9/9/07, Raymond Feng <[EMAIL PROTECTED]> wrote:


Hi,

I have been thinking of this problem as well. It's not realistic 
to search
for all CallableReferences because it can be dynamically created 
too. We



Agreed. You would have to have registered them somewhere first. 
This is what

happens in the case of the conversation scope container currently.

probably need to use a listener pattern to have all the 
Conversation objects
listen on the events of expirati

Re: Including the SCA spec XSDs in the Tuscany distribution?

[Jean-Sebastien Delfino]

ant elder wrote:

On 9/7/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
  

This has come up several times but I've not seen any conclusion.

Here are the relevant JIRAs:
http://issues.apache.org/jira/browse/TUSCANY-181
http://issues.apache.org/jira/browse/TUSCANY-678
http://issues.apache.org/jira/browse/TUSCANY-1389

To resolve these JIRAs I think we should include the SCA XSDs [1] in the
Tuscany distribution.

Is there any issue with the SCA license [2] preventing us to include the
XSDs?

Is the license going to change now that SCA is being standardized at
OASIS?

Thoughts?

[1] http://www.osoa.org/xmlns/sca/1.0/
[2] http://www.osoa.org/xmlns/sca/1.0/license.txt

--
Jean-Sebastien




I think it should be fine to include them as we already include some other
things which also use that OSOA license in previous SCA and SDO releases.

It would be interesting to know if the license will be changed to something
more standard with the move to OASIS.

   ...ant

  


OK, if there's no objection, I'll go ahead and include the XSDs. This 
will allow us to do a number of interesting things:


- Validate SCA assembly XML when loading .composite, .componentType, 
.constrainingType, improving our error reporting story. I'll try to see 
how we can just leverage Validating StAX XMLStreamReaders for that.


- Document how to register the XSDs in an IDE like Eclipse and get 
validation there too, again improving the error reporting story. We may 
even be able to provide a simple plugin.xml file that you can drop in 
your IDE and does the XSD registration for you.


- Define XSDs for our various implementation and binding extensions, 
extending the core SCA XSDs. I think it is important to help document them.


More on this in the next 2 days if I find a little bit of time to work 
on it...


--
Jean-Sebastien


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WS-Addressing mapping (was Re: What is Message.set/getCallableReference used for?)

[Simon Nash]

See inline.

  Simon

Raymond Feng wrote:


Comments inline.

Thanks,
Raymond

- Original Message - From: "Simon Nash" <[EMAIL PROTECTED]>
To: 
Sent: Tuesday, September 11, 2007 7:47 AM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)




Thanks for pointing out this issue.  I think we're OK with just
using ConversationID as the correlator as long as we make the
following assumptions:

 1. The correlation from ConversationID to callback object is done
on a per-reference basis.



Are you assuming for the lifecylce of a conversation, there is only one 
effective callback object for a given service reference?

>
Yes.  This seems consistent with the following spec words: "...callback
messages go to the client and are then routed to the specific instance
that has been registered as the callback object".  See further comments
below on this.

 Even so, we 
still need to do some correlations (using the callback endpoint URI as 
the key?) to relate a callback to the given service reference, right?



Logically yes, but I don't think any explicit correlation on endpoint
URI is needed.  I was expecting each callback endpoint to keep its own
correlation table that maps ConversationID to callback object.  (This
is probably just a particular implementation of what you are saying.)


 2. The callback goes to the callback object that is set into the
reference at the time the callback is made, not at the time
the forward call is made.

Consider the following code:

  myRef = componentContext.getServiceReference(convInterface, refName);
  myRef.setCallback(callback1);
  myRef.getService().startConversation();
  myRef.setCallback(callback2);
  myRef.getService().continueConversation();
  myRef.setCallback(callback3);



Are you saying if the myRef.setCallback() is called for multiple times, 
the effective callback object will override the previous one? If so and 
if startConversation() and contineConversation() are one-way async 
operations, the result is unpredictable.



Yes, I am saying that.  The situation won't arise unless someone changes
the callback object after making an async call.  If the callback object
were never set, then all callbacks would go to a single instance of the
client component.  It seems reasonable to think of the callback object
as a way of redirecting callbacks from this single instance to a different
single instance on the client side, rather than a way of redirecting
callbacks to multiple client-side instances on a per-call basis.

Another way to look at this is that the callback object instance becomes
part of the state of the conversation.  This seems consistent with the
requirement that a callback object that isn't a service reference can
only be used with a stateful callback.  If a different unique
correlation ID were used to locate the callback object, there would
be no need for the stateful callback limitation.


With the assumptions listed above, the callbacks from startConversation()
and continueConversation() would go to callback3 (the current value)
instead of callback1 and callback2 respectively (the values at the time
of the forward calls).  I don't see anything in the spec that says that
this is not correct.



Assuming both the forward call and callback are synchronous, if the 
callback happens in the startConversation() method of the target 
service, then it will go to callback1, right? In this case, the 
setCallback(callback2) hasn't even been called.



Yes, thanks for the clarification.  I realised just as I pushed Send that
I hadn't been clear that I was thinking of the async case where callbacks
arrived after all the code had been executed.

  Simon



Does this take care of the cases you had in mind?

  Simon

Raymond Feng wrote:


+1 on the proposal. There is one more thing to add.

For the case that the callback object is not a ServiceReference, we 
don't flow it in the Message, but we still need to correlate the 
callback to this object so that the callback can be routed to the 
right callback object. ConversationID alone is good enough, because
we can use different callback objects in the same conversation. I 
suggest that we add a "CallbackObjectID" to reference parameter under 
the CallbackReference. The CallbackObjectID can be the system hash 
code of the callback object. The ConversationID + CallbackObjectID 
will be the key for the correlation.


Do you agree?

Thanks,
Raymond

- Original Message - From: "Jean-Sebastien Delfino" 
<[EMAIL PROTECTED]>

To: 
Sent: Monday, September 10, 2007 3:43 PM
Subject: Re: WS-Addressing mapping (was Re: What is 
Message.set/getCallableReference used for?)




Comments inline.

[snip]
Simon Nash wrote:

I agree that we need a conclusion.  I believe the detailed proposal 
below
supports all the SCA semantics and I'd like to propose that we go 
with it

for Tuscany 1.0.

Any comments, questions, agreem

Re: Release management for 1.0 release, was: Release management for next release, was: SCA 0.92 release?

[Venkata Krishnan]

+1 from me.  I'd be happy to help wherever required.

- Venkat

On 9/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>
> Ant has been doing a great job as Release Manager for several releases.
> I'd like to nominate him as Release Manager for release 1.0, as it's
> going to be a pretty important milestone release for the project, and
> I'm sure he'll make it a successful release again!
>
> Thoughts?
>
> [snip]
> ant elder wrote:
> > Taking the branch on the 14th and making an RC1 on the 14th is possible,
> > just the RC is likely to be a little rough as there won't be much time
> at
> > all to do checking. But as we're talking about RC1 not expected to be
> _the_
> > RC then i guess that could be fine.
> >
> >...ant
> >
> >
>
> --
> Jean-Sebastien
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: How to handle business exceptions not easily serializable to XML

[Simon Nash]

Yes, I think this should work.  I'm trying to get a simple case
through the Web Service binding and the databinding transformers at the
moment and I'm running into various issues.  I'll post a more detailed
update later.

  Simon

Scott Kurz wrote:


Say I wanted to have a remotable Java interface with a method like:

 int myMethod() throws java.sql.SQLException;

Should I be able to throw this exception, say, across the web service
binding?

I don't see why not.JAX-WS Sec 3.7 describes how to build a fault bean
out of an exception like SQLException which doesn't conform to the pattern
in JAX-WS Sec 2.5. A tool like wsgen should be able to generate a WSDL
with a corresponding fault element, typed by the default mapping obtained by
viewing SQLException as a JavaBean (Sec 3.7) per JAXB.

(For a complicated data type the default JAXB mapping isn't enough without
annotations, but for simpler examples it might be OK.)

Do we view this as a valid remote interface?   I'm not asking whether it
works today.. just whether it seems like it should work.

Scott





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Incompatibility between Tuscany and JBoss WebServices

[haleh mahbod]

Thank you.

On 9/11/07, Marco Dalco <[EMAIL PROTECTED]> wrote:
>
> Raised a JIRA:
>
>
>
> https://issues.apache.org/jira/browse/TUSCANY-1684
>
>
>
>
> Information contained in this e-mail and any attachments are intended for
> the use of the addressee only, and may contain confidential information of
> Ubiquity Software Corporation. All unauthorized use, disclosure or
> distribution is strictly prohibited.  If you are not the addressee, please
> notify the sender immediately and destroy all copies of this email. Ubiquity
> Software Corporation plc, a company registered under the laws of England and
> Wales, Registration 2719723, registered offices at Eastern Business Park,
> Building 3, Wern Fawr Lane, St. Mellons, Cardiff CF3 5EA, Wales, United
> Kingdom.
>
>

Re: Release management for 1.0 release, was: Release management for next release, was: SCA 0.92 release?

[Simon Nash]

+1 for Ant.

  Simon

Venkata Krishnan wrote:


+1 from me.  I'd be happy to help wherever required.

- Venkat

On 9/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:


Ant has been doing a great job as Release Manager for several releases.
I'd like to nominate him as Release Manager for release 1.0, as it's
going to be a pretty important milestone release for the project, and
I'm sure he'll make it a successful release again!

Thoughts?

[snip]
ant elder wrote:


Taking the branch on the 14th and making an RC1 on the 14th is possible,
just the RC is likely to be a little rough as there won't be much time


at


all to do checking. But as we're talking about RC1 not expected to be


_the_


RC then i guess that could be fine.

  ...ant




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

Improving Store sample to describe client JSON and Atom references

[Jean-Sebastien Delfino]

I checked in a version of the Store sample described in the Getting 
Started document a while ago.


I'd like to describe a few thoughts on how to improve the sample with 
small changes to the sample itself and some improvements to the 
implementation.resource extension and how it integrates with Web 
2.0-friendly bindings.


The current Store sample looks like this:

store.composite
http://www.osoa.org/xmlns/sca/1.0";
   xmlns:t="http://tuscany.apache.org/xmlns/sca/1.0";
   xmlns:s="http://store"; 
   name="store">

   

   
   
   
 

 
   

   USD

   
   
  
   target="CurrencyConverter"/> 

 
   

   
   
   

   
   
   

   





store.html


Store





   //Reference
   catalog = (new JSONRpcClient("../Catalog/")).Catalog;
   //Reference
   shoppingCart = new AtomClient("../ShoppingCart/");