Re: Conversational state in 2.x

[Florian Moga]

I have just committed an initial implementation of multiple response support
as discussed above. Feel free to review the comet binding runtime [1] and to
give a try to the new version of the comet binding sample [2]. To do that,
please make sure you are using the latest core [3], otherwise NPEs are
likely to appear.

Looking forward to upgrade the module to the new async service support by
following your guidelines.

[1]
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/binding-comet-runtime/
[2]
http://svn.apache.org/repos/asf/tuscany/sca-java-2.x/contrib/samples/learning-more/binding-comet/weather-webapp/

[3]
https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/core/

On Tue, Feb 1, 2011 at 5:20 PM, Florian MOGA  wrote:

> Hi Mike,
>
> A few comments inline:
>
> On Tue, Feb 1, 2011 at 4:03 PM, Mike Edwards <
> mike.edwards.inglen...@gmail.com> wrote:
>>
>> Florian,
>>
>> First, let's be clear that Conversational interactions were deliberately
>> removed from SCA V1.1 by the OASIS spec group because of their complexity -
>> and they were also removed from Tuscany 2.0 to match.
>>
>> However, I am not sure that Conversational is what you're really looking
>> for.
>
>
>
> Let me play back what I think you're wanting.
>>
>> From what you say, the function that you're looking for is for the binding
>> code (in the Comet binding in your case) to be able to store some
>> binding-specific data on a forward request call that is then later accessed
>> by the binding code when a callback is made to that original request.
>>
>
> That is exactly right.
>
>
>> Logically, what you're really looking for is the capability for the
>> binding to place some binding-specific data into the Callback object and for
>> the binding code to be able to access this data at the point where the
>> Callback object is invoked.  And one thing to note about this is that the
>> Callback object *might* be serialized between the initial request and the
>> callback - PLUS it is very likely that a different thread will be used to do
>> the callback - so that thread local stuff simply is not going to work.
>>
>
> The case of the comet binding is that it only has a service side becase the
> 'reference' side is a collection of javascript proxies that are injected
> into the browser page. This means that the whole callback mechanism doesn't
> involve passing data through the wire, it's an operation that happens
> server-side exclusively and then the callback response is sent through the
> native async capabilities of comet back to the browser. Does that still
> imply the possibility of serialization and decoupling from the original
> thread? At the moment the server-side callback mechanism is actually
> sequential (the service method implementation is an infinite loop that sends
> a response via the callback object every X seconds synchronously) and I'm
> not that happy with it.
>
> In order to make things work I had to make the forward service invocation
> with a manually constructed Message on which I've set a mock
> RuntimeEndpointReferenceImpl on the 'from' property so that Tuscany
> internals won't throw NPEs. This means that when the callback is invoked I'm
> not having an actual implementation of the callback interface that I'm
> calling, I'm just handling the operations in the Invoker.
>
> I've been doing this kind of thing for the async service support that has
>> been added recently - and I noticed that the callback mechanism is nowhere
>> near as powerful as the new async code.
>>
>> The async stuff has an internal object called the AsyncResponseInvoker
>> that is used to carry data between the forward invocation and the response -
>> and this includes binding-specific information. This object is also
>> serializable and forms part of the serialization processes used by the
>> service implementation.
>>
>> Currently, the callback processing does not use this approach - but I
>> think that it should.  I think that a similar "CallbackInvoker" should be
>> created in the processing of the forward request - and that it should form
>> part of the callback object state that is serializable.  It should have the
>> capability for the binding to insert and retrieve whatever information is
>> required.
>>
>
>  That sounds great. When do you think something like the CallbackInvoker
> will be available in Tuscany?
>
>
>> Does this thinking hit the mark?
>>
>
> Totally, thank you for the detailed response. I'll try and finish up the
> remaining refactorings and commit an initial version early next week. We can
> have a more proper discussion alongside with the code. It would be great if
> you could review it and give me some suggestions on how to use the new async
> service support.
>
>
>>
>> Yours,  Mike.
>>
>>
> Florian
>

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash]

ant elder wrote:

On Fri, Feb 11, 2011 at 10:17 AM, ant elder  wrote:

On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash  wrote:



Actually I would wonder what is the point of using maven to generate
an ant script that does exactly the same as the maven build.

In 1.x the ant scripts were provided as an alternative to maven that
use local artifacts from the binary distro instead of depending on
remote repositories.


I meant to add, if working offline using local artifacts is
useful/important then i wonder if that should also be possible with
the Maven builds in the binary distribution. It might be nice if both
the Ant and Maven builds could both work offline using the
distribution artifacts, which would probably mean having the jars in
the hierarchical directory structure that maven uses and having the
Tuscany standalone runtimes work with that. At least that would then
have the jars in a fairly common and understandable structure.

   ...ant



From this I presume you mean having these jars under the Tuscany
installation directory rather than in the user's local maven repo.

This seems like a good idea as it's first step to creating a more
embeddable Tuscany runtime installation.

  Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash]

ant elder wrote:

On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash  wrote:

ant elder wrote:

On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga  wrote:


I'm not keen into having an ant build file in every sample. If someone
wants
to use ant, shouldn't they download all dependencies manually? Won't they
use maven for that task anyway? What about ivy?


I've been thinking the same thing lately, especially now that you
pointed out that we can do "mvn ant:ant" to have Ant scripts
automatically generated. Instead of Ant builds for each sample there
could just be some doc in the top level samples folder or README that
describes how to use "mvn ant:ant".

The build scripts generated with mvn ant:ant download all the
dependencies from the Maven repositories, that does mean that not much
would be actually using all the jars from the Tuscany binary
distribution so we might want to consider what all thats really for.

  ...ant



Actually I would wonder what is the point of using maven to generate
an ant script that does exactly the same as the maven build.

In 1.x the ant scripts were provided as an alternative to maven that
use local artifacts from the binary distro instead of depending on
remote repositories.  Another purpose was to make it very clear and
explicit what steps are involved "under the covers" to build and run
Tuscany applications.  This information is useful to people who want
to develop solutions that embed Tuscany.

 Simon




In 1.x at least some of the Ant scripts are/were just generated from
the maven build but using the Tuscany plugin instead of the Ant plugin
aren't they, so its not so different?


Many of these are generated, but they use local jars rather than
downloading them from maven repositories, and the Ant scripts are
included in the binary distro so there's no need for users to have
maven to create them.  In some cases only the list of dependencies
is generated as build-dependency.xml, and this is included by a
hand-written build.xml file.


I think we need to agree what the purpose of them is, what it is that
they're demonstrating, and then decide if the best way to show that is
a separate sample(s), or to include both Maven and Ant in every
sample, I'm wondering if separate might be better.


I think that's a good suggestion.  For a group of samples where the
building/running logistics are similar, we could just provide one
Ant script.  For samples where the logistics are substantially different,
a separate Ant script could be provided.  This reduces the considerable
burden of providing a working tested Ant script for every sample.


One think is that the 2.x distribution is a bit unusual with the way
it stores the jars in both top and subdirectories, and there are now
all the generated manifest jars, and the various aggregated jars. I
can't imagine anyone would have their own jars in this sort of mix so
i wonder how useful the hand written Ant builds which use them really
would be.

   ...ant



Isn't that quite a problem for the embedded scenario?  Developing an
application that embeds Tuscany isn't particularly easy even with the
simpler 1.x structure.  What would we recommend to someone who wants
to develop a Tuscany application using 2.x that embeds/redistributes
the Tuscany runtime?

  Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder]

On Fri, Feb 11, 2011 at 10:17 AM, ant elder  wrote:
> On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash  wrote:

>> Actually I would wonder what is the point of using maven to generate
>> an ant script that does exactly the same as the maven build.
>>
>> In 1.x the ant scripts were provided as an alternative to maven that
>> use local artifacts from the binary distro instead of depending on
>> remote repositories.

I meant to add, if working offline using local artifacts is
useful/important then i wonder if that should also be possible with
the Maven builds in the binary distribution. It might be nice if both
the Ant and Maven builds could both work offline using the
distribution artifacts, which would probably mean having the jars in
the hierarchical directory structure that maven uses and having the
Tuscany standalone runtimes work with that. At least that would then
have the jars in a fairly common and understandable structure.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder]

On Fri, Feb 11, 2011 at 9:24 AM, Simon Nash  wrote:
> ant elder wrote:
>>
>> On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga  wrote:
>>
>>> I'm not keen into having an ant build file in every sample. If someone
>>> wants
>>> to use ant, shouldn't they download all dependencies manually? Won't they
>>> use maven for that task anyway? What about ivy?
>>>
>>
>> I've been thinking the same thing lately, especially now that you
>> pointed out that we can do "mvn ant:ant" to have Ant scripts
>> automatically generated. Instead of Ant builds for each sample there
>> could just be some doc in the top level samples folder or README that
>> describes how to use "mvn ant:ant".
>>
>> The build scripts generated with mvn ant:ant download all the
>> dependencies from the Maven repositories, that does mean that not much
>> would be actually using all the jars from the Tuscany binary
>> distribution so we might want to consider what all thats really for.
>>
>>   ...ant
>>
>>
> Actually I would wonder what is the point of using maven to generate
> an ant script that does exactly the same as the maven build.
>
> In 1.x the ant scripts were provided as an alternative to maven that
> use local artifacts from the binary distro instead of depending on
> remote repositories.  Another purpose was to make it very clear and
> explicit what steps are involved "under the covers" to build and run
> Tuscany applications.  This information is useful to people who want
> to develop solutions that embed Tuscany.
>
>  Simon
>
>

In 1.x at least some of the Ant scripts are/were just generated from
the maven build but using the Tuscany plugin instead of the Ant plugin
aren't they, so its not so different?

I think we need to agree what the purpose of them is, what it is that
they're demonstrating, and then decide if the best way to show that is
a separate sample(s), or to include both Maven and Ant in every
sample, I'm wondering if separate might be better.

One think is that the 2.x distribution is a bit unusual with the way
it stores the jars in both top and subdirectories, and there are now
all the generated manifest jars, and the various aggregated jars. I
can't imagine anyone would have their own jars in this sort of mix so
i wonder how useful the hand written Ant builds which use them really
would be.

   ...ant

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[Simon Nash]

ant elder wrote:

On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga  wrote:


I'm not keen into having an ant build file in every sample. If someone wants
to use ant, shouldn't they download all dependencies manually? Won't they
use maven for that task anyway? What about ivy?



I've been thinking the same thing lately, especially now that you
pointed out that we can do "mvn ant:ant" to have Ant scripts
automatically generated. Instead of Ant builds for each sample there
could just be some doc in the top level samples folder or README that
describes how to use "mvn ant:ant".

The build scripts generated with mvn ant:ant download all the
dependencies from the Maven repositories, that does mean that not much
would be actually using all the jars from the Tuscany binary
distribution so we might want to consider what all thats really for.

   ...ant



Actually I would wonder what is the point of using maven to generate
an ant script that does exactly the same as the maven build.

In 1.x the ant scripts were provided as an alternative to maven that
use local artifacts from the binary distro instead of depending on
remote repositories.  Another purpose was to make it very clear and
explicit what steps are involved "under the covers" to build and run
Tuscany applications.  This information is useful to people who want
to develop solutions that embed Tuscany.

  Simon

Re: 2.0 Beta2 samples (was: [VOTE] Release Tuscany SCA 2.0 Beta2 RC2)

[ant elder]

On Thu, Feb 10, 2011 at 10:36 AM, Florian Moga  wrote:

> I'm not keen into having an ant build file in every sample. If someone wants
> to use ant, shouldn't they download all dependencies manually? Won't they
> use maven for that task anyway? What about ivy?
>

I've been thinking the same thing lately, especially now that you
pointed out that we can do "mvn ant:ant" to have Ant scripts
automatically generated. Instead of Ant builds for each sample there
could just be some doc in the top level samples folder or README that
describes how to use "mvn ant:ant".

The build scripts generated with mvn ant:ant download all the
dependencies from the Maven repositories, that does mean that not much
would be actually using all the jars from the Tuscany binary
distribution so we might want to consider what all thats really for.

   ...ant

Re: 2.x module NOTICE and LICENSE files

[ant elder]

On Thu, Feb 10, 2011 at 2:24 PM, Simon Laws  wrote:
> I note that the default maven-remote-resources-plugin  configuration
> now generates default NOTICE and LICENSE files in each modules
> target/maven-shared-archive-resources directory. These files are then
> copied into the META-INF directory of each module.
>
> As we have hand crafted NOTICE and LICENSE files in some modules, e.g.
> assembly-xsd, you end up with module jars containing two sets of
> NOTICE and LICENSE files which are different. My first reaction would
> be to turn off the auto generated versions.
>
> Thoughts?
>
> Simon
>

Just turning off the generated ones does seem the simplest for now to
fix the immediate problem.

I have been wondering though if we should use this in the samples.
There was that user thread the other day [1] that made me think about
how the samples work and its all a bit complicated as we try to
prevent them getting deployed. If that was just to stop the clutter of
having the legal files in the source then having the legal files get
auto generated avoids that, and then we can simplify the build and
deploy.

It is also possible to have the modules that need more than the
standard text customize what goes in the generated files so modules
like assembly-xsd could do that to get their extra license text.

   ...ant

[1] http://apache.markmail.org/message/nl64lf2jgykhv4ju