jolie-devel — Jolie development mailing list

Re: [Jolie-devel] XML support / documentation

[Claudio G. <cg...@it...>]

if you use = you are just assigning the root node value of test not the
entire tree.
You have to copy the entire tree. So you can:

1) xml.root << test (deep copy: all the subtree of test is copied into
xml.root)
2) xml.root -> test  (link: xml.root points to the content of test. No data
copies are done)

Cheers
Claudio

--------------------------------------------------------------
Claudio Guidi Ph.D.
italianaSoftware s.r.l.
via Coralli, 66 - 40026 Imola (BO), Italy
http://www.italianasoftware.com/
http://www.jolie-lang.org
Phone: +39 0542 788201
Mobile: +39 347 0694065
Fax: +39 0542 628048
--------------------------------------------------------------

Nota di riservatezza: Il presente messaggio, corredato dei
relativi allegati, contiene informazioni da considerarsi strettamente
riservate, ed è destinato esclusivamente al destinatario sopra indicato, il
quale è l'unico autorizzato ad usarlo, copiarlo e, sotto la propria
responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore
o comunque lo leggesse senza esserne legittimato è avvertito che
trattenerlo, copiarlo,divulgarlo, distribuirlo a persone diverse dal
destinatario è severamente proibito, ed è pregato di rinviarlo
immediatamente al mittente distruggendone l'originale.

Grazie per la collaborazione.


2013/12/21 Matthias Dieter Wallnöfer <mwa...@ya...>

> Hi devs,
>
> yet another question.
>
> How is the call "valueToXml" on port "XmlUtils" supposed to work?
>
> For instance an example like this does not work...
> >   test.a = 4;
> >   test.b = 7.5;
> >   test.c.d = "hi";
> >
> >   xml.rootNodeName = "doc";
> >   xml.root = test;
> >   valueToXml@XmlUtils(xml)(content);
> >   println@Console(content)();
>
> Cheers,
> Matthias
>
> Matthias Dieter Wallnöfer schrieb:
> > Hi devs,
> >
> > for my project I would like to acquire an XML (configuration) file.
> > "content" and "conf" are free variables.
> >>    with (readFileRequest) {
> >>      .filename = configFile
> >>    };
> >>    readFile@File(readFileRequest)(content);
> >>    content.options.includeAttributes = true;
> >>    xmlToValue@XmlUtils(content)(conf);
> > This works smoothly although I got two questions:
> >
> > - what does "includeAttributes" mean?
> > - does there exist a way to perform a XSD parsing as well? Do I need to
> > include some tag in the XML file to make this happen?
> >
> > I am sorry, but the documentation
> > (
> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=jsl/XmlUtils
> )
> > is very superficial in this area.
> >
> > Cheers,
> > Matthias
> >
> >
> >
> ------------------------------------------------------------------------------
> > Rapidly troubleshoot problems before they affect your business. Most IT
> > organizations don't have a clear picture of how application performance
> > affects their revenue. With AppDynamics, you get 100% visibility into
> your
> > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
> AppDynamics Pro!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Jolie-devel mailing list
> > Jol...@li...
> > https://lists.sourceforge.net/lists/listinfo/jolie-devel
>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>

Re: [Jolie-devel] XML support / documentation

[Matthias D. W. <mwa...@ya...>]

Hi devs,

yet another question.

How is the call "valueToXml" on port "XmlUtils" supposed to work?

For instance an example like this does not work...
>   test.a = 4;
>   test.b = 7.5;
>   test.c.d = "hi";
>
>   xml.rootNodeName = "doc";
>   xml.root = test;
>   valueToXml@XmlUtils(xml)(content);
>   println@Console(content)();

Cheers,
Matthias

Matthias Dieter Wallnöfer schrieb:
> Hi devs,
>
> for my project I would like to acquire an XML (configuration) file.
> "content" and "conf" are free variables.
>>    with (readFileRequest) {
>>      .filename = configFile
>>    };
>>    readFile@File(readFileRequest)(content);
>>    content.options.includeAttributes = true;
>>    xmlToValue@XmlUtils(content)(conf);
> This works smoothly although I got two questions:
>
> - what does "includeAttributes" mean?
> - does there exist a way to perform a XSD parsing as well? Do I need to
> include some tag in the XML file to make this happen?
>
> I am sorry, but the documentation
> (http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=jsl/XmlUtils)
> is very superficial in this area.
>
> Cheers,
> Matthias
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel

[Jolie-devel] XML support / documentation

[Matthias D. W. <mwa...@ya...>]

Hi devs,

for my project I would like to acquire an XML (configuration) file. 
"content" and "conf" are free variables.
>   with (readFileRequest) {
>     .filename = configFile
>   };
>   readFile@File(readFileRequest)(content);
>   content.options.includeAttributes = true;
>   xmlToValue@XmlUtils(content)(conf);
This works smoothly although I got two questions:

- what does "includeAttributes" mean?
- does there exist a way to perform a XSD parsing as well? Do I need to 
include some tag in the XML file to make this happen?

I am sorry, but the documentation 
(http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=jsl/XmlUtils) 
is very superficial in this area.

Cheers,
Matthias

Re: [Jolie-devel] Await mechanism

[Fabrizio M. <fam...@gm...>]

No. We usually implement this kind of stuff using message exchanges
with an embedded service, written in Jolie or Java.

There are actually a lot of common usage patterns, so some time ago I
started coding a standard Concurrency service in the Jolie library,
but I never had time to get around something stable..

We do have though a synchronized construct:

synchronized( NameOfLock ) { .... code .... }

where NameOfLock is just any name, which will represent the lock.
Locks are globally shared in the same service.



- Fabrizio

On Thu, Dec 19, 2013 at 12:49 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi,
>
> I wanted to ask if Jolie supports some await mechanism. The
> documentation does not say anything about it.
>
> E.g.: I would like to make a call blocking until some global variable
> becomes 0. Then I need some "synchronized" construct as well?
>
>>   [ finished()() { await until #global.numCars == 0 } ] { nullProcess }
>
> Cheers,
> Matthias
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Jolie-devel mailing list
> Jol...@li...
> https://lists.sourceforge.net/lists/listinfo/jolie-devel

[Jolie-devel] Await mechanism

[Matthias D. W. <mwa...@ya...>]

Hi,

I wanted to ask if Jolie supports some await mechanism. The 
documentation does not say anything about it.

E.g.: I would like to make a call blocking until some global variable 
becomes 0. Then I need some "synchronized" construct as well?

>   [ finished()() { await until #global.numCars == 0 } ] { nullProcess }

Cheers,
Matthias

Re: [Jolie-devel] OneWay messages

[Matthias D. W. <mwa...@ya...>]

Hi Fabrizio,

indeed it seems to work. I appreciate it very much that the various bugs 
get fixed :).

I notice that Jolie is a very clever language.

Cheers,
Matthias

Fabrizio Montesi schrieb:
> Thanks a lot for the example and the patch Matthias. Turns out that it
> wasn't the client's fault, it was the server's!
> Basically, the server was shutting down too early, without waiting for
> the thread responsible for sending the acknowledgment of message
> reception to the client to finish its duty correctly
> (CommChannelHandler).
>
> I've inserted a reader-writer lock to solve the problem: each
> commchannelhandler is a reader and the interpreter exiting procedure
> is the writer, so when the interpreter wants to terminate it has to
> wait for all the "readers" to finish.
>
> Client now works for me. Let me know if it works for you too.
>
> Cheers,
> Fabrizio.
>

Re: [Jolie-devel] OneWay messages

[Fabrizio M. <fam...@gm...>]

Thanks a lot for the example and the patch Matthias. Turns out that it
wasn't the client's fault, it was the server's!
Basically, the server was shutting down too early, without waiting for
the thread responsible for sending the acknowledgment of message
reception to the client to finish its duty correctly
(CommChannelHandler).

I've inserted a reader-writer lock to solve the problem: each
commchannelhandler is a reader and the interpreter exiting procedure
is the writer, so when the interpreter wants to terminate it has to
wait for all the "readers" to finish.

Client now works for me. Let me know if it works for you too.

Cheers,
Fabrizio.


On Mon, Dec 16, 2013 at 12:24 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi Fabrizio,
>
> I notice that the client does not terminate anymore with my patch. The
> attachment contains the simplest example.
>
>
> Cheers,
> Matthias
>
> Fabrizio Montesi schrieb:
>>
>> Hi Matthias,
>> generally, it looks fine, but what do you mean by "There is still
>> something missing, since server and client processes do not exit after
>> a simple one-way communication message." ?
>>
>> Do you have a simple example that I can run to understand?
>>
>> Cheers,
>> Fabrizio.
>>
>> On Tue, Dec 10, 2013 at 5:48 PM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>>
>>> Hi,
>>>
>>> this is a first idea. There is still something missing, since server and
>>> client processes do not exit after a simple one-way communication
>>> message.
>>>
>>>
>>> Matthias
>>>
>>> Fabrizio Montesi schrieb:
>>>>
>>>> Hi Matthias,
>>>> sorry for the late reply, I've been pretty busy with my PhD.
>>>>
>>>> Yes, I think that could work!
>>>>
>>>> Wanna try change SODEPProtocol? I think that a possible fix could be
>>>> to catch EOFException there in the first read (that for the message
>>>> id) and rethrow it as a ChannelClosedException.
>>>>
>>>> Cheers,
>>>> Fabrizio.
>>>>
>>>> On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
>>>> <mwa...@ya...> wrote:
>>>>>
>>>>> Any news on this one?
>>>>>
>>>>> Matthias Dieter Wallnöfer schrieb:
>>>>>
>>>>>> Hi Fabrizio,
>>>>>>
>>>>>> yes, the easiest would be to extend ChannelClosedException from
>>>>>> EOFException? So very little changes would be necessary. Otherwise we
>>>>>> would need to extend each method's signature.
>>>>>>
>>>>>> Cheers,
>>>>>> Matthias
>>>>>>
>>>>>> Fabrizio Montesi schrieb:
>>>>>>>
>>>>>>> Hi Matthias,
>>>>>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>>>>>> like that (just prints that on screen) depending on the underlying OS
>>>>>>> and network. It is consistent when using localhost afaik.
>>>>>>>
>>>>>>> Basically, every output port channel is handled by a separate thread,
>>>>>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>>>>>> new messages on the channel and puts them in cache when the
>>>>>>> interpreter is ready to receive a response for an operation (in the
>>>>>>> case of one-way such responses are just ACKs that the messages have
>>>>>>> been put in the channel cache on the other side).
>>>>>>>
>>>>>>> So, you have that thread on the client waiting on the channel, and
>>>>>>> the
>>>>>>> server suddenly goes down because it terminates execution. Then, the
>>>>>>> client throws that exception.
>>>>>>>
>>>>>>> The problem in handling this gracefully is that we should
>>>>>>> differentiate between an EOFException that we get in the middle of
>>>>>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>>>>>> general CommProtocol.recv()), or the same exception got when trying
>>>>>>> to
>>>>>>> receive the first bit of information (which is your case if you look
>>>>>>> at the source code at SodepProtocol.java:252).
>>>>>>> Then, the protocol could throw a custom exception that we create
>>>>>>> (ChannelClosedException?) representing a graceful channel closing and
>>>>>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>>>>>
>>>>>>> Let me know if you'd be interested in tackling this.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Fabrizio.
>>>>>>>
>>>>>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>
>>>>>>>> Hi Fabrizio,
>>>>>>>>
>>>>>>>> this works well, but on the client side
>>>>>>>>>
>>>>>>>>> main
>>>>>>>>> {
>>>>>>>>>         twice@TwiceService( 5 )
>>>>>>>>> }
>>>>>>>>
>>>>>>>> I get a Java EOF exception. I imagine that this could be a
>>>>>>>> coordination
>>>>>>>> issue?
>>>>>>>>>
>>>>>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>>>>>> WARNING: [client.ol] java.io.EOFException
>>>>>>>>>         at
>>>>>>>>> java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>>>>>>         at
>>>>>>>>> java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>>>>>>         at
>>>>>>>>> jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>>>>>>         at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>>>>>>         at
>>>>>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>>>>>>         at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>>>>>>         at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>>>>>>         at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>>>         at
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>>>         at java.lang.Thread.run(Thread.java:724)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>> Fabrizio Montesi schrieb:
>>>>>>>>
>>>>>>>>> Hi Matthias,
>>>>>>>>> this:
>>>>>>>>>>
>>>>>>>>>> twice( number ) {
>>>>>>>>>>              result = number * 2;
>>>>>>>>>>              println@Console( result )();
>>>>>>>>>>          }
>>>>>>>>>
>>>>>>>>> is not a construct in the language. Request-Response operations
>>>>>>>>> support the { block } construct because it is useful to specify
>>>>>>>>> something to happen *in-between* the request and the response. For
>>>>>>>>> one-ways this is not necessary because they just receive something.
>>>>>>>>> Hence you can just use the semicolon operator for expressing a
>>>>>>>>> sequence and obtain what you want:
>>>>>>>>>
>>>>>>>>> twice( number );
>>>>>>>>> result = number * 2;
>>>>>>>>> println@Console( result )()
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Fabrizio.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi developers,
>>>>>>>>>>
>>>>>>>>>> I got another question: in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>>>>>> we have a simple client-server example:
>>>>>>>>>>>
>>>>>>>>>>> |main|
>>>>>>>>>>> |{|
>>>>>>>>>>> |||twice( number )( response ) {|
>>>>>>>>>>> |||response = number * ||2|
>>>>>>>>>>> |||}|
>>>>>>>>>>> |}|
>>>>>>>>>>
>>>>>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>>>>>
>>>>>>>>>>> interface TwiceInterface {
>>>>>>>>>>>          OneWay: twice( int )
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>> main
>>>>>>>>>>> {
>>>>>>>>>>>          twice( number ) {
>>>>>>>>>>>              result = number * 2;
>>>>>>>>>>>              println@Console( result )();
>>>>>>>>>>>          }
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> does not work. Why?
>>>>>>>>>>
>>>>>>>>>> Do I need something like this?
>>>>>>>>>>>
>>>>>>>>>>> main
>>>>>>>>>>> {
>>>>>>>>>>>          [ twice( number ) ] {
>>>>>>>>>>>              result = number * 2;
>>>>>>>>>>>              println@Console( result )();
>>>>>>>>>>>          }
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Matthias
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>>>>>> innovation.
>>>>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>>>>>> game-changing
>>>>>>>>>> conversations that shape the rapidly evolving mobile landscape.
>>>>>>>>>> Sign
>>>>>>>>>> up
>>>>>>>>>> now.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Jolie-devel mailing list
>>>>>>>>>> Jol...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>> innovation.
>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>> game-changing
>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>> up
>>>>>> now.
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Jolie-devel mailing list
>>>>>> Jol...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>>
>>>>>
>

Re: [Jolie-devel] Documentation indentation fix

[Matthias D. W. <mwa...@ya...>]

Thank you and a merry Christmas as well!

Matthias

Saverio Giallorenzo schrieb:
> Hi,
> sorry, did see that.
> Done.
>
>
> 2013/12/18 Matthias Dieter Wallnöfer <mwa...@ya... 
> <mailto:mwa...@ya...>>
>
>     Hi Saverio,
>
>     and the indentation patches?
>
>     Matthias
>
>     Saverio Giallorenzo schrieb:
>
>         Hi Matthias,
>         patch applied.
>
>         Thanks and Merry Christmas :)
>
>
>         2013/12/18 Matthias Dieter Wallnöfer <mwa...@ya...
>         <mailto:mwa...@ya...> <mailto:mwa...@ya...
>         <mailto:mwa...@ya...>>>
>
>
>             Hi Saverio,
>
>             there is some other fix regarding "with".
>
>             Matthias
>
>

Re: [Jolie-devel] Documentation indentation fix

[Saverio G. <sav...@gm...>]

Hi,
sorry, did see that.
Done.


2013/12/18 Matthias Dieter Wallnöfer <mwa...@ya...>

> Hi Saverio,
>
> and the indentation patches?
>
> Matthias
>
> Saverio Giallorenzo schrieb:
>
>> Hi Matthias,
>> patch applied.
>>
>> Thanks and Merry Christmas :)
>>
>>
>> 2013/12/18 Matthias Dieter Wallnöfer <mwa...@ya... <mailto:
>> mwa...@ya...>>
>>
>>
>>     Hi Saverio,
>>
>>     there is some other fix regarding "with".
>>
>>     Matthias
>>
>>

Re: [Jolie-devel] Documentation indentation fix

[Matthias D. W. <mwa...@ya...>]

Hi Saverio,

and the indentation patches?

Matthias

Saverio Giallorenzo schrieb:
> Hi Matthias,
> patch applied.
>
> Thanks and Merry Christmas :)
>
>
> 2013/12/18 Matthias Dieter Wallnöfer <mwa...@ya... 
> <mailto:mwa...@ya...>>
>
>     Hi Saverio,
>
>     there is some other fix regarding "with".
>
>     Matthias
>

Re: [Jolie-devel] Documentation indentation fix

[Saverio G. <sav...@gm...>]

Hi Matthias,
patch applied.

Thanks and Merry Christmas :)


2013/12/18 Matthias Dieter Wallnöfer <mwa...@ya...>

> Hi Saverio,
>
> there is some other fix regarding "with".
>
> Matthias
>
> Matthias Dieter Wallnöfer schrieb:
>
>> Hi Saverio,
>>
>> could I apply the following patch?
>>
>> Matthias
>>
>
>

Re: [Jolie-devel] Documentation indentation fix

[Matthias D. W. <mwa...@ya...>]

Hi Saverio,

there is some other fix regarding "with".

Matthias

Matthias Dieter Wallnöfer schrieb:
> Hi Saverio,
>
> could I apply the following patch?
>
> Matthias

[Jolie-devel] Received a non correlating message

[Matthias D. W. <mwa...@ya...>]

Hi Fabrizio,

for another university course I have to develop some sort of Formula 1 
simulator. I asked myself if it would be possible to do this in Jolie, 
and as far as I figured out it seems to be.

The cars I modeled as independent threads using dynamic embedding to get 
an arbitrary number of them. So I managed to get a still very basic 
prototype to run, but under some race condition it fails.
> Warnung: [car.ol] Received a non correlating message for operation 
> create. Sending CorrelationError to the caller.
Is this a bug in Jolie? Or I am just making some wrong assumptions?

Cheers,
Matthias

Re: [Jolie-devel] OneWay messages

[Matthias D. W. <mwa...@ya...>]

Hi Fabrizio,

I notice that the client does not terminate anymore with my patch. The 
attachment contains the simplest example.

Cheers,
Matthias

Fabrizio Montesi schrieb:
> Hi Matthias,
> generally, it looks fine, but what do you mean by "There is still
> something missing, since server and client processes do not exit after
> a simple one-way communication message." ?
>
> Do you have a simple example that I can run to understand?
>
> Cheers,
> Fabrizio.
>
> On Tue, Dec 10, 2013 at 5:48 PM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
>> Hi,
>>
>> this is a first idea. There is still something missing, since server and
>> client processes do not exit after a simple one-way communication message.
>>
>>
>> Matthias
>>
>> Fabrizio Montesi schrieb:
>>> Hi Matthias,
>>> sorry for the late reply, I've been pretty busy with my PhD.
>>>
>>> Yes, I think that could work!
>>>
>>> Wanna try change SODEPProtocol? I think that a possible fix could be
>>> to catch EOFException there in the first read (that for the message
>>> id) and rethrow it as a ChannelClosedException.
>>>
>>> Cheers,
>>> Fabrizio.
>>>
>>> On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
>>> <mwa...@ya...> wrote:
>>>> Any news on this one?
>>>>
>>>> Matthias Dieter Wallnöfer schrieb:
>>>>
>>>>> Hi Fabrizio,
>>>>>
>>>>> yes, the easiest would be to extend ChannelClosedException from
>>>>> EOFException? So very little changes would be necessary. Otherwise we
>>>>> would need to extend each method's signature.
>>>>>
>>>>> Cheers,
>>>>> Matthias
>>>>>
>>>>> Fabrizio Montesi schrieb:
>>>>>> Hi Matthias,
>>>>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>>>>> like that (just prints that on screen) depending on the underlying OS
>>>>>> and network. It is consistent when using localhost afaik.
>>>>>>
>>>>>> Basically, every output port channel is handled by a separate thread,
>>>>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>>>>> new messages on the channel and puts them in cache when the
>>>>>> interpreter is ready to receive a response for an operation (in the
>>>>>> case of one-way such responses are just ACKs that the messages have
>>>>>> been put in the channel cache on the other side).
>>>>>>
>>>>>> So, you have that thread on the client waiting on the channel, and the
>>>>>> server suddenly goes down because it terminates execution. Then, the
>>>>>> client throws that exception.
>>>>>>
>>>>>> The problem in handling this gracefully is that we should
>>>>>> differentiate between an EOFException that we get in the middle of
>>>>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>>>>> general CommProtocol.recv()), or the same exception got when trying to
>>>>>> receive the first bit of information (which is your case if you look
>>>>>> at the source code at SodepProtocol.java:252).
>>>>>> Then, the protocol could throw a custom exception that we create
>>>>>> (ChannelClosedException?) representing a graceful channel closing and
>>>>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>>>>
>>>>>> Let me know if you'd be interested in tackling this.
>>>>>>
>>>>>> Cheers,
>>>>>> Fabrizio.
>>>>>>
>>>>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>>>>> <mwa...@ya...> wrote:
>>>>>>> Hi Fabrizio,
>>>>>>>
>>>>>>> this works well, but on the client side
>>>>>>>> main
>>>>>>>> {
>>>>>>>>         twice@TwiceService( 5 )
>>>>>>>> }
>>>>>>> I get a Java EOF exception. I imagine that this could be a
>>>>>>> coordination
>>>>>>> issue?
>>>>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>>>>> WARNING: [client.ol] java.io.EOFException
>>>>>>>>         at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>>>>>         at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>>>>>         at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>>>>>         at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>>>>>         at
>>>>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>>>>>         at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>>>>>         at
>>>>>>>>
>>>>>>>>
>>>>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>>>>>         at
>>>>>>>>
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>>         at
>>>>>>>>
>>>>>>>>
>>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>>         at java.lang.Thread.run(Thread.java:724)
>>>>>>> Cheers,
>>>>>>> Matthias
>>>>>>>
>>>>>>> Fabrizio Montesi schrieb:
>>>>>>>
>>>>>>>> Hi Matthias,
>>>>>>>> this:
>>>>>>>>> twice( number ) {
>>>>>>>>>              result = number * 2;
>>>>>>>>>              println@Console( result )();
>>>>>>>>>          }
>>>>>>>> is not a construct in the language. Request-Response operations
>>>>>>>> support the { block } construct because it is useful to specify
>>>>>>>> something to happen *in-between* the request and the response. For
>>>>>>>> one-ways this is not necessary because they just receive something.
>>>>>>>> Hence you can just use the semicolon operator for expressing a
>>>>>>>> sequence and obtain what you want:
>>>>>>>>
>>>>>>>> twice( number );
>>>>>>>> result = number * 2;
>>>>>>>> println@Console( result )()
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Fabrizio.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>> Hi developers,
>>>>>>>>>
>>>>>>>>> I got another question: in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>>>>> we have a simple client-server example:
>>>>>>>>>> |main|
>>>>>>>>>> |{|
>>>>>>>>>> |||twice( number )( response ) {|
>>>>>>>>>> |||response = number * ||2|
>>>>>>>>>> |||}|
>>>>>>>>>> |}|
>>>>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>>>> interface TwiceInterface {
>>>>>>>>>>          OneWay: twice( int )
>>>>>>>>>> }
>>>>>>>>> and
>>>>>>>>>> main
>>>>>>>>>> {
>>>>>>>>>>          twice( number ) {
>>>>>>>>>>              result = number * 2;
>>>>>>>>>>              println@Console( result )();
>>>>>>>>>>          }
>>>>>>>>>> }
>>>>>>>>> does not work. Why?
>>>>>>>>>
>>>>>>>>> Do I need something like this?
>>>>>>>>>> main
>>>>>>>>>> {
>>>>>>>>>>          [ twice( number ) ] {
>>>>>>>>>>              result = number * 2;
>>>>>>>>>>              println@Console( result )();
>>>>>>>>>>          }
>>>>>>>>>> }
>>>>>>>>> Cheers,
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>>>>> innovation.
>>>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>>>>> game-changing
>>>>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>>>>> up
>>>>>>>>> now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>>>>> _______________________________________________
>>>>>>>>> Jolie-devel mailing list
>>>>>>>>> Jol...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Shape the Mobile Experience: Free Subscription
>>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>> game-changing
>>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>>> now.
>>>>>
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Jolie-devel mailing list
>>>>> Jol...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>

Re: [Jolie-devel] wsdl2jolie patches

[Matthias D. W. <mwa...@ya...>]

Okay,

and the rest of the patch?

Matthias

Claudio Guidi schrieb:
> commit done
>
> --------------------------------------------------------------
> Claudio Guidi Ph.D.
> italianaSoftware s.r.l.
> via Coralli, 66 - 40026 Imola (BO), Italy
> http://www.italianasoftware.com/
> http://www.jolie-lang.org <http://www.jolie-lang.org/>
> Phone: +39 0542 788201
> Mobile: +39 347 0694065
> Fax: +39 0542 628048
> --------------------------------------------------------------
>
> Nota di riservatezza: Il presente messaggio, corredato dei 
> relativi allegati, contiene informazioni da considerarsi strettamente 
> riservate, ed è destinato esclusivamente al destinatario sopra 
> indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto 
> la propria responsabilità,diffonderlo. Chiunque ricevesse questo 
> messaggio per errore o comunque lo leggesse senza esserne legittimato 
> è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a 
> persone diverse dal destinatario è severamente proibito, ed è pregato 
> di rinviarlo immediatamente al mittente distruggendone l'originale.
>
> Grazie per la collaborazione.
>
>
> 2013/12/13 Claudio Guidi <cg...@it... 
> <mailto:cg...@it...>>
>
>     we already had, I just added the condition
>
>     --------------------------------------------------------------
>     Claudio Guidi Ph.D.
>     italianaSoftware s.r.l.
>     via Coralli, 66 - 40026 Imola (BO), Italy
>     http://www.italianasoftware.com/
>     http://www.jolie-lang.org <http://www.jolie-lang.org/>
>     Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>     Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>     Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>     --------------------------------------------------------------
>
>     Nota di riservatezza: Il presente messaggio, corredato dei
>     relativi allegati, contiene informazioni da considerarsi
>     strettamente riservate, ed è destinato esclusivamente al
>     destinatario sopra indicato, il quale è l'unico autorizzato ad
>     usarlo, copiarlo e, sotto la propria responsabilità,diffonderlo.
>     Chiunque ricevesse questo messaggio per errore o comunque
>     lo leggesse senza esserne legittimato è avvertito che trattenerlo,
>     copiarlo,divulgarlo, distribuirlo a persone diverse dal
>     destinatario è severamente proibito, ed è pregato di rinviarlo
>     immediatamente al mittente distruggendone l'originale.
>
>     Grazie per la collaborazione.
>
>
>     2013/12/13 Fabrizio Montesi <fam...@gm...
>     <mailto:fam...@gm...>>
>
>         Is checkSkippedTypes something we already had or something new?
>
>         Cheers,
>         Fabrizio.
>
>         On Thu, Dec 12, 2013 at 7:34 PM, Matthias Dieter Wallnöfer
>         <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>         > Hi Claudio,
>         >
>         > that's fine, please apply :-).
>         >
>         > Matthias
>         >
>         > Claudio Guidi schrieb:
>         >>
>         >> Hi Matthias,
>         >>
>         >>
>         >> I made some tests and I would patch your patch :-) with the
>         following
>         >> code:
>         >>
>         >> if ( (particle = contentType.asParticle()) == null &&
>         !checkSkippedTypes(
>         >> element.getName(), element.getTargetNamespace() )) {
>         >>                     jolieTypes.add( createAnyOrUndefined(
>         >> element.getName(), complexType ) );
>         >>                     continue;
>         >>                 }
>         >>
>         >> I added   && !checkSkippedTypes( element.getName(),
>         >> element.getTargetNamespace() ) which avoid to process basic
>         element types.
>         >>
>         >> So, Matthias could apply the patch with my modifications?
>         >>
>         >> --------------------------------------------------------------
>         >> Claudio Guidi Ph.D.
>         >> italianaSoftware s.r.l.
>         >> via Coralli, 66 - 40026 Imola (BO), Italy
>         >> http://www.italianasoftware.com/
>         >> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>         >> Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>         >> Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>         >> Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>         >> --------------------------------------------------------------
>         >>
>         >> Nota di riservatezza: Il presente messaggio, corredato dei
>         relativi
>         >> allegati, contiene informazioni da considerarsi
>         strettamente riservate, ed è
>         >> destinato esclusivamente al destinatario sopra indicato, il
>         quale è l'unico
>         >> autorizzato ad usarlo, copiarlo e, sotto la propria
>         >> responsabilità,diffonderlo. Chiunque ricevesse questo
>         messaggio per errore o
>         >> comunque lo leggesse senza esserne legittimato è avvertito
>         che trattenerlo,
>         >> copiarlo,divulgarlo, distribuirlo a persone diverse dal
>         destinatario è
>         >> severamente proibito, ed è pregato di rinviarlo
>         immediatamente al mittente
>         >> distruggendone l'originale.
>         >>
>         >> Grazie per la collaborazione.
>         >>
>         >>
>         >> 2013/12/12 Claudio Guidi <cg...@it...
>         <mailto:cg...@it...>
>         >> <mailto:cg...@it...
>         <mailto:cg...@it...>>>
>         >>
>         >>
>         >>     Hi guys,
>         >>
>         >>     I made some tests with a more complex wsdl. In the
>         following what
>         >>     I found:
>         >>
>         >>     1) if a insert the line that Matthias has commented
>         >>     (jolieTypes.add( createAnyOrUndefined( element.getName(),
>         >>     complexType ) );) in the final interface I will found
>         basic types
>         >>     declarations such as
>         >>
>         >>     type boolean:undefined
>         >>     type string:undefined
>         >>
>         >>     So far it is not clear to me when exactly happens. I
>         need more
>         >>     time for investigating.
>         >>
>         >>     Thus, I think we need more test before enabling the patch.
>         >>
>         >>
>         >>     new issues!!!
>         >>     2) XSOMParser seems to not process import tags where
>         >>     schemaLocation is not defined. Ex:
>         >>     <s:import
>         namespace="http://schemas.xmlsoap.org/soap/encoding/">
>         >>
>         >>     if you change the line into:
>         >>     <s:import
>         namespace="http://schemas.xmlsoap.org/soap/encoding/"
>         >>    
>         schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
>         >>     it wroks.
>         >>
>         >>     But this is quite annoying because if the wsdl is
>         generated (as in
>         >>     my case) without schemaLocation you always need to
>         download the
>         >>     file,add schemaLocation attributes to all the imports
>         and then
>         >>     launch the wsdl2jolie locally. It's a nightmare!
>         >>     I tried to google the problem but I didn't find
>         anything useful,
>         >>     could you help me to find some fixes? Maybe we need to
>         update the
>         >>     XSOM library?
>         >>
>         >>     3) at the present, if the message of an operation
>         contains more
>         >>     than one part, the conversion could fail. Ex:
>         >>
>         >>     <s:schema targetNamespace="blablabla">
>         >>           <s:import
>         >>     namespace="http://schemas.xmlsoap.org/soap/encoding/"
>         >>    
>         schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
>         >>           <s:complexType name="HomerSimpsons">
>         >>             some complex content
>         >>             </s:complexContent>
>         >>           </s:complexType>
>         >>         </s:schema>
>         >>
>         >>       <wsdl:message name="MYMessage">
>         >>         <wsdl:part name="part1" type="s:string" />
>         >>         <wsdl:part name="part2" type="s1:HomerSimpsons" />
>         >>       </wsdl:message>
>         >>
>         >>     <wsdl:operation name="operationName">
>         >>           <wsdl:input message="tns:MyMessage" />
>         >>           <wsdl:output message="tns:AnotherMessage" />
>         >>         </wsdl:operation>
>         >>
>         >>     Unfortunately I cannot attach the wsdl file because it
>         is private
>         >>     and protected by copyright.
>         >>     This is a limitation we have so far.
>         >>
>         >>
>         >>
>         >>
>         >> --------------------------------------------------------------
>         >>     Claudio Guidi Ph.D.
>         >>     italianaSoftware s.r.l.
>         >>     via Coralli, 66 - 40026 Imola (BO), Italy
>         >> http://www.italianasoftware.com/
>         >> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>         >>     Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>         <tel:%2B39%200542%20788201>
>         >>     Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>         <tel:%2B39%20347%200694065>
>         >>     Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>         <tel:%2B39%200542%20628048>
>         >>
>         >> --------------------------------------------------------------
>         >>
>         >>     Nota di riservatezza: Il presente messaggio, corredato dei
>         >>     relativi allegati, contiene informazioni da considerarsi
>         >>     strettamente riservate, ed è destinato esclusivamente al
>         >>     destinatario sopra indicato, il quale è l'unico
>         autorizzato ad
>         >>     usarlo, copiarlo e, sotto la propria
>         responsabilità,diffonderlo.
>         >>     Chiunque ricevesse questo messaggio per errore o comunque
>         >>     lo leggesse senza esserne legittimato è avvertito che
>         trattenerlo,
>         >>     copiarlo,divulgarlo, distribuirlo a persone diverse dal
>         >>     destinatario è severamente proibito, ed è pregato di
>         rinviarlo
>         >>     immediatamente al mittente distruggendone l'originale.
>         >>
>         >>     Grazie per la collaborazione.
>         >>
>         >>
>         >>     2013/12/10 Fabrizio Montesi <fam...@gm...
>         <mailto:fam...@gm...>
>         >>     <mailto:fam...@gm... <mailto:fam...@gm...>>>
>         >>
>         >>
>         >>         That'd be great. We should also think about adding
>         them to the
>         >>         test suite somehow..
>         >>
>         >>         Sent from my phone.
>         >>
>         >>         On Dec 10, 2013 8:12 PM, "Claudio Guidi"
>         >>         <cg...@it...
>         <mailto:cg...@it...>
>         >>         <mailto:cg...@it...
>         <mailto:cg...@it...>>> wrote:
>         >>
>         >>             If you give me some days I'll try to check the
>         code with
>         >>             some complex wsdl.
>         >>
>         >>             Il 10/dic/2013 20:00 "Fabrizio Montesi"
>         >>             <fam...@gm...
>         <mailto:fam...@gm...> <mailto:fam...@gm...
>         <mailto:fam...@gm...>>> ha scritto:
>         >>
>         >>
>         >>                 Claudio, do you have an example for raising
>         that error?
>         >>
>         >>                 - Fabrizio
>         >>
>         >>                 On Tue, Dec 10, 2013 at 7:07 PM, Matthias
>         Dieter Wallnöfer
>         >>                 <mwa...@ya...
>         <mailto:mwa...@ya...> <mailto:mwa...@ya...
>         <mailto:mwa...@ya...>>>
>         >>
>         >>                 wrote:
>         >>                 > We should try to understand where and why the
>         >>                 generation of
>         >>                 >>
>         >>                 >> type undefined:undefined
>         >>                 >
>         >>                 > happened.
>         >>                 >
>         >>                 > Just to make sure - I did not get it in
>         my case
>         >>                 (when un-commenting this
>         >>                 > particular codeline).
>         >>                 >
>         >>                 > Matthias
>         >>                 >
>         >>                 > Fabrizio Montesi schrieb:
>         >>                 >
>         >>                 >> No, I mean that your type should be
>         generated:
>         >>                 >>
>         >>                 >> type GetWeatherInformation:undefined
>         >>                 >>
>         >>                 >> whereas the following should not be
>         generated:
>         >>                 >>
>         >>                 >> type undefined:undefined
>         >>                 >>
>         >>                 >>
>         >>                 >> by implementing some check on the name
>         of the type
>         >>                 we are generating,
>         >>                 >> to avoid redefining undefined. The
>         latter is our
>         >>                 main problem
>         >>                 >> (@Claudio: right?).
>         >>                 >>
>         >>                 >>
>         >>                 >>
>         >>                 >> Ciao,
>         >>                 >> Fabrizio.
>         >>                 >>
>         >>                 >> On Tue, Dec 10, 2013 at 5:55 PM,
>         Matthias Dieter
>         >>                 Wallnöfer
>         >>                 >> <mwa...@ya...
>         <mailto:mwa...@ya...>
>         >>                 <mailto:mwa...@ya...
>         <mailto:mwa...@ya...>>> wrote:
>         >>                 >>>
>         >>                 >>> Hi Fabrizio,
>         >>                 >>>
>         >>                 >>> did I get your point?
>         >>                 >>>
>         >>                 >>> You think that declarations as
>         >>                 >>>>
>         >>                 >>>> type GetWeatherInformation:undefined
>         >>                 >>>
>         >>                 >>> should be omitted and all
>         "GetWeatherInformation"
>         >>                 appearances immediately
>         >>                 >>> be
>         >>                 >>> substituted by "undefined"?
>         >>                 >>>
>         >>                 >>> Btw. in the WSDL file it is declared
>         like this
>         >>                 >>>
>         (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>         >>                 >>>
>         >>                 >>>> <s:element
>         >> name="GetWeatherInformation"><s:complexType/></s:element>
>         >>                 >>>
>         >>                 >>> So to be honest I do not see an issue
>         to include
>         >>                 it in Jolie's header as
>         >>                 >>> well. The right thing would be to
>         change the
>         >>                 webservice to not include
>         >>                 >>> empty
>         >>                 >>> complex types!
>         >>                 >>>
>         >>                 >>> Matthias
>         >>                 >>>
>         >>                 >>> Fabrizio Montesi schrieb:
>         >>                 >>>
>         >>                 >>>> Mmh... a possible solution could be
>         that we add a
>         >>                 check that verifies
>         >>                 >>>> whether we're creating a type with the
>         same name
>         >>                 of a predefined type
>         >>                 >>>> in Jolie (in which case we should not
>         create the
>         >>                 type) or not (in
>         >>                 >>>> which case we should create the type).
>         >>                 >>>>
>         >>                 >>>> What do you think?
>         >>                 >>>>
>         >>                 >>>> If this can work, the systematic way
>         of doing it
>         >>                 would be to have some
>         >>                 >>>> constant set or enum defined somewhere
>         which
>         >>                 contains the names of all
>         >>                 >>>> predefined types (I think we can reuse
>         some
>         >>                 predefined map from the
>         >>                 >>>> parser).
>         >>                 >>>>
>         >>                 >>>> - Fabrizio
>         >>                 >>>>
>         >>                 >>>> On Tue, Dec 10, 2013 at 5:11 PM,
>         Matthias Dieter
>         >>                 Wallnöfer
>         >>                 >>>> <mwa...@ya...
>         <mailto:mwa...@ya...>
>         >>                 <mailto:mwa...@ya...
>         <mailto:mwa...@ya...>>> wrote:
>         >>                 >>>>>
>         >>                 >>>>> Hi all,
>         >>                 >>>>>
>         >>                 >>>>> not really correct. It generates
>         types like
>         >>                 "type <name>:undefined",
>         >>                 >>>>> for
>         >>                 >>>>> instance in my case:
>         >> >>>>>>
>         >> >>>>>> type GetWeatherInformation:undefined
>         >>                 >>>>>
>         >>                 >>>>> So this is required in some cases.
>         >>                 >>>>>
>         >>                 >>>>> Cheers,
>         >>                 >>>>> Matthias
>         >>                 >>>>>
>         >>                 >>>>> Claudio Guidi schrieb:
>         >> >>>>>>
>         >> >>>>>> Hi all,
>         >> >>>>>>
>         >> >>>>>> sorry for the delay.
>         >> >>>>>>
>         >> >>>>>> Do you mean this line?
>         >> >>>>>>
>         >> >>>>>> jolieTypes.add( createAnyOrUndefined(
>         >>                 element.getName(), complexType )
>         >> >>>>>> );
>         >> >>>>>>
>         >> >>>>>> If I remember well it was commented because,
>         >>                 otherwise, you will find
>         >> >>>>>>
>         >> >>>>>> type undefined: undefined
>         >> >>>>>>
>         >> >>>>>> into the generated interface.
>         >> >>>>>>
>         >> >>>>>>
>         >> >>>>>>
>         >> >>>>>>
>         >>
>         >> --------------------------------------------------------------
>         >> >>>>>> Claudio Guidi Ph.D.
>         >> >>>>>> italianaSoftware s.r.l.
>         >> >>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>         >> >>>>>> http://www.italianasoftware.com/
>         >> >>>>>> http://www.jolie-lang.org
>         >>                 <http://www.jolie-lang.org/>
>         >> >>>>>>
>         >> >>>>>> Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>         <tel:%2B39%200542%20788201>
>         >> >>>>>> Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>         <tel:%2B39%20347%200694065>
>         >> >>>>>> Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>         <tel:%2B39%200542%20628048>
>         >>
>         >> >>>>>>
>         >>
>         >> --------------------------------------------------------------
>         >> >>>>>>
>         >> >>>>>> Nota di riservatezza: Il presente messaggio,
>         >>                 corredato dei relativi
>         >> >>>>>> allegati, contiene informazioni da considerarsi
>         >>                 strettamente
>         >> >>>>>> riservate,
>         >> >>>>>> ed è
>         >> >>>>>> destinato esclusivamente al destinatario sopra
>         >>                 indicato, il quale è
>         >> >>>>>> l'unico
>         >> >>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>         >> >>>>>> responsabilità,diffonderlo. Chiunque ricevesse
>         >>                 questo messaggio per
>         >> >>>>>> errore o
>         >> >>>>>> comunque lo leggesse senza esserne legittimato
>         >>                 è avvertito che
>         >> >>>>>> trattenerlo,
>         >> >>>>>> copiarlo,divulgarlo, distribuirlo a persone
>         >>                 diverse dal destinatario è
>         >> >>>>>> severamente proibito, ed è pregato di rinviarlo
>         >>                 immediatamente al
>         >> >>>>>> mittente
>         >> >>>>>> distruggendone l'originale.
>         >> >>>>>>
>         >> >>>>>> Grazie per la collaborazione.
>         >> >>>>>>
>         >> >>>>>>
>         >> >>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>         <mailto:fam...@gm...>
>         >>                 <mailto:fam...@gm...
>         <mailto:fam...@gm...>>
>         >> >>>>>> <mailto:fam...@gm... <mailto:fam...@gm...>
>         >>
>         >>                 <mailto:fam...@gm...
>         <mailto:fam...@gm...>>>>
>         >> >>>>>>
>         >> >>>>>>
>         >> >>>>>>       Hi all,
>         >> >>>>>>
>         >> >>>>>> @Claudio: do you have any info on that line?
>         >> >>>>>>
>         >> >>>>>>       Cheers,
>         >> >>>>>> Fabrizio.
>         >> >>>>>>
>         >> >>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias
>         >>                 Dieter Wallnöfer
>         >> >>>>>>       <mwa...@ya...
>         <mailto:mwa...@ya...>
>         >>                 <mailto:mwa...@ya...
>         <mailto:mwa...@ya...>>
>         >>                 <mailto:mwa...@ya...
>         <mailto:mwa...@ya...>
>         >>
>         >>                 <mailto:mwa...@ya...
>         <mailto:mwa...@ya...>>>> wrote:
>         >> >>>>>>       > Any news on this one (and also on the
>         >>                 Exception thing: Re:
>         >> >>>>>> [Jolie-devel]
>         >> >>>>>>       > OneWay messages)?
>         >> >>>>>>       >
>         >> >>>>>>       > Matthias
>         >> >>>>>>       >
>         >> >>>>>>       > Fabrizio Montesi schrieb:
>         >> >>>>>>       >
>         >> >>>>>> >> Hi all,
>         >> >>>>>> >> I'm trying to see why that line has been
>         >>                 commented...
>         >> >>>>>> especially since
>         >> >>>>>> >> it has been commented without leaving any
>         >>                 other comment
>         >> >>>>>> explaining the
>         >> >>>>>> >> reason in the code. Claudio, any memories? :-)
>         >> >>>>>> >>
>         >> >>>>>> >> I see it's commented out in many parts of
>         >>                 the code.
>         >> >>>>>> >>
>         >> >>>>>> >>
>         >> >>>>>> >> Cheers,
>         >> >>>>>> >> Fabrizio.
>         >> >>>>>>       >
>         >> >>>>>>       >
>         >> >>>>>>
>         >> >>>>>>
>         >>                 >
>         >>
>         >>
>         >>
>         >
>
>
>

Re: [Jolie-devel] OneWay messages

[Fabrizio M. <fam...@gm...>]

Hi Matthias,
generally, it looks fine, but what do you mean by "There is still
something missing, since server and client processes do not exit after
a simple one-way communication message." ?

Do you have a simple example that I can run to understand?

Cheers,
Fabrizio.

On Tue, Dec 10, 2013 at 5:48 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi,
>
> this is a first idea. There is still something missing, since server and
> client processes do not exit after a simple one-way communication message.
>
>
> Matthias
>
> Fabrizio Montesi schrieb:
>>
>> Hi Matthias,
>> sorry for the late reply, I've been pretty busy with my PhD.
>>
>> Yes, I think that could work!
>>
>> Wanna try change SODEPProtocol? I think that a possible fix could be
>> to catch EOFException there in the first read (that for the message
>> id) and rethrow it as a ChannelClosedException.
>>
>> Cheers,
>> Fabrizio.
>>
>> On Fri, Nov 29, 2013 at 10:08 AM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>>
>>> Any news on this one?
>>>
>>> Matthias Dieter Wallnöfer schrieb:
>>>
>>>> Hi Fabrizio,
>>>>
>>>> yes, the easiest would be to extend ChannelClosedException from
>>>> EOFException? So very little changes would be necessary. Otherwise we
>>>> would need to extend each method's signature.
>>>>
>>>> Cheers,
>>>> Matthias
>>>>
>>>> Fabrizio Montesi schrieb:
>>>>>
>>>>> Hi Matthias,
>>>>> yeah, we have an annoying bug that doesn't really hurt but appears
>>>>> like that (just prints that on screen) depending on the underlying OS
>>>>> and network. It is consistent when using localhost afaik.
>>>>>
>>>>> Basically, every output port channel is handled by a separate thread,
>>>>> that jolie.net.AbstractCommChannel$ResponseReceiver, which waits for
>>>>> new messages on the channel and puts them in cache when the
>>>>> interpreter is ready to receive a response for an operation (in the
>>>>> case of one-way such responses are just ACKs that the messages have
>>>>> been put in the channel cache on the other side).
>>>>>
>>>>> So, you have that thread on the client waiting on the channel, and the
>>>>> server suddenly goes down because it terminates execution. Then, the
>>>>> client throws that exception.
>>>>>
>>>>> The problem in handling this gracefully is that we should
>>>>> differentiate between an EOFException that we get in the middle of
>>>>> parsing a received message in a protocol (e.g., SODEP, but more in
>>>>> general CommProtocol.recv()), or the same exception got when trying to
>>>>> receive the first bit of information (which is your case if you look
>>>>> at the source code at SodepProtocol.java:252).
>>>>> Then, the protocol could throw a custom exception that we create
>>>>> (ChannelClosedException?) representing a graceful channel closing and
>>>>> catch it from jolie.net.AbstractCommChannel$ResponseReceiver.
>>>>>
>>>>> Let me know if you'd be interested in tackling this.
>>>>>
>>>>> Cheers,
>>>>> Fabrizio.
>>>>>
>>>>> On Thu, Nov 21, 2013 at 11:53 AM, Matthias Dieter Wallnöfer
>>>>> <mwa...@ya...> wrote:
>>>>>>
>>>>>> Hi Fabrizio,
>>>>>>
>>>>>> this works well, but on the client side
>>>>>>>
>>>>>>> main
>>>>>>> {
>>>>>>>        twice@TwiceService( 5 )
>>>>>>> }
>>>>>>
>>>>>> I get a Java EOF exception. I imagine that this could be a
>>>>>> coordination
>>>>>> issue?
>>>>>>>
>>>>>>> Nov 21, 2013 11:49:30 AM jolie.Interpreter logWarning
>>>>>>> WARNING: [client.ol] java.io.EOFException
>>>>>>>        at java.io.DataInputStream.readFully(DataInputStream.java:197)
>>>>>>>        at java.io.DataInputStream.readLong(DataInputStream.java:416)
>>>>>>>        at jolie.net.SodepProtocol.readMessage(SodepProtocol.java:252)
>>>>>>>        at jolie.net.SodepProtocol.recv(SodepProtocol.java:305)
>>>>>>>        at
>>>>>>> jolie.net.SocketCommChannel.recvImpl(SocketCommChannel.java:92)
>>>>>>>        at jolie.net.CommChannel.recv(CommChannel.java:198)
>>>>>>>        at
>>>>>>>
>>>>>>>
>>>>>>> jolie.net.AbstractCommChannel$ResponseReceiver.run(AbstractCommChannel.java:226)
>>>>>>>        at
>>>>>>>
>>>>>>>
>>>>>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>        at
>>>>>>>
>>>>>>>
>>>>>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>        at java.lang.Thread.run(Thread.java:724)
>>>>>>
>>>>>> Cheers,
>>>>>> Matthias
>>>>>>
>>>>>> Fabrizio Montesi schrieb:
>>>>>>
>>>>>>> Hi Matthias,
>>>>>>> this:
>>>>>>>>
>>>>>>>> twice( number ) {
>>>>>>>>             result = number * 2;
>>>>>>>>             println@Console( result )();
>>>>>>>>         }
>>>>>>>
>>>>>>> is not a construct in the language. Request-Response operations
>>>>>>> support the { block } construct because it is useful to specify
>>>>>>> something to happen *in-between* the request and the response. For
>>>>>>> one-ways this is not necessary because they just receive something.
>>>>>>> Hence you can just use the semicolon operator for expressing a
>>>>>>> sequence and obtain what you want:
>>>>>>>
>>>>>>> twice( number );
>>>>>>> result = number * 2;
>>>>>>> println@Console( result )()
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Fabrizio.
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 21, 2013 at 11:04 AM, Matthias Dieter Wallnöfer
>>>>>>> <mwa...@ya...> wrote:
>>>>>>>>
>>>>>>>> Hi developers,
>>>>>>>>
>>>>>>>> I got another question: in
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.jolie-lang.org/?top_menu=documentation&sideMenuAction=getting_started/behavior_and_deployment
>>>>>>>> we have a simple client-server example:
>>>>>>>>>
>>>>>>>>> |main|
>>>>>>>>> |{|
>>>>>>>>> |||twice( number )( response ) {|
>>>>>>>>> |||response = number * ||2|
>>>>>>>>> |||}|
>>>>>>>>> |}|
>>>>>>>>
>>>>>>>> But when I change it to be one-way I run into trouble:
>>>>>>>>>
>>>>>>>>> interface TwiceInterface {
>>>>>>>>>         OneWay: twice( int )
>>>>>>>>> }
>>>>>>>>
>>>>>>>> and
>>>>>>>>>
>>>>>>>>> main
>>>>>>>>> {
>>>>>>>>>         twice( number ) {
>>>>>>>>>             result = number * 2;
>>>>>>>>>             println@Console( result )();
>>>>>>>>>         }
>>>>>>>>> }
>>>>>>>>
>>>>>>>> does not work. Why?
>>>>>>>>
>>>>>>>> Do I need something like this?
>>>>>>>>>
>>>>>>>>> main
>>>>>>>>> {
>>>>>>>>>         [ twice( number ) ] {
>>>>>>>>>             result = number * 2;
>>>>>>>>>             println@Console( result )();
>>>>>>>>>         }
>>>>>>>>> }
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>>>> innovation.
>>>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>>>> game-changing
>>>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>>>> up
>>>>>>>> now.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>>>> _______________________________________________
>>>>>>>> Jolie-devel mailing list
>>>>>>>> Jol...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Shape the Mobile Experience: Free Subscription
>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>> game-changing
>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>> now.
>>>>
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Jolie-devel mailing list
>>>> Jol...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jolie-devel
>>>
>>>
>

Re: [Jolie-devel] wsdl2jolie patches

[Fabrizio M. <fam...@gm...>]

Is checkSkippedTypes something we already had or something new?

Cheers,
Fabrizio.

On Thu, Dec 12, 2013 at 7:34 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi Claudio,
>
> that's fine, please apply :-).
>
> Matthias
>
> Claudio Guidi schrieb:
>>
>> Hi Matthias,
>>
>>
>> I made some tests and I would patch your patch :-) with the following
>> code:
>>
>> if ( (particle = contentType.asParticle()) == null && !checkSkippedTypes(
>> element.getName(), element.getTargetNamespace() )) {
>>                     jolieTypes.add( createAnyOrUndefined(
>> element.getName(), complexType ) );
>>                     continue;
>>                 }
>>
>> I added   && !checkSkippedTypes( element.getName(),
>> element.getTargetNamespace() ) which avoid to process basic element types.
>>
>> So, Matthias could apply the patch with my modifications?
>>
>> --------------------------------------------------------------
>> Claudio Guidi Ph.D.
>> italianaSoftware s.r.l.
>> via Coralli, 66 - 40026 Imola (BO), Italy
>> http://www.italianasoftware.com/
>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>> Phone: +39 0542 788201
>> Mobile: +39 347 0694065
>> Fax: +39 0542 628048
>> --------------------------------------------------------------
>>
>> Nota di riservatezza: Il presente messaggio, corredato dei relativi
>> allegati, contiene informazioni da considerarsi strettamente riservate, ed è
>> destinato esclusivamente al destinatario sopra indicato, il quale è l'unico
>> autorizzato ad usarlo, copiarlo e, sotto la propria
>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore o
>> comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo,
>> copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è
>> severamente proibito, ed è pregato di rinviarlo immediatamente al mittente
>> distruggendone l'originale.
>>
>> Grazie per la collaborazione.
>>
>>
>> 2013/12/12 Claudio Guidi <cg...@it...
>> <mailto:cg...@it...>>
>>
>>
>>     Hi guys,
>>
>>     I made some tests with a more complex wsdl. In the following what
>>     I found:
>>
>>     1) if a insert the line that Matthias has commented
>>     (jolieTypes.add( createAnyOrUndefined( element.getName(),
>>     complexType ) );) in the final interface I will found basic types
>>     declarations such as
>>
>>     type boolean:undefined
>>     type string:undefined
>>
>>     So far it is not clear to me when exactly happens. I need more
>>     time for investigating.
>>
>>     Thus, I think we need more test before enabling the patch.
>>
>>
>>     new issues!!!
>>     2) XSOMParser seems to not process import tags where
>>     schemaLocation is not defined. Ex:
>>     <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/">
>>
>>     if you change the line into:
>>     <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/"
>>     schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
>>     it wroks.
>>
>>     But this is quite annoying because if the wsdl is generated (as in
>>     my case) without schemaLocation you always need to download the
>>     file,add schemaLocation attributes to all the imports and then
>>     launch the wsdl2jolie locally. It's a nightmare!
>>     I tried to google the problem but I didn't find anything useful,
>>     could you help me to find some fixes? Maybe we need to update the
>>     XSOM library?
>>
>>     3) at the present, if the message of an operation contains more
>>     than one part, the conversion could fail. Ex:
>>
>>     <s:schema targetNamespace="blablabla">
>>           <s:import
>>     namespace="http://schemas.xmlsoap.org/soap/encoding/"
>>     schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
>>           <s:complexType name="HomerSimpsons">
>>             some complex content
>>             </s:complexContent>
>>           </s:complexType>
>>         </s:schema>
>>
>>       <wsdl:message name="MYMessage">
>>         <wsdl:part name="part1" type="s:string" />
>>         <wsdl:part name="part2" type="s1:HomerSimpsons" />
>>       </wsdl:message>
>>
>>     <wsdl:operation name="operationName">
>>           <wsdl:input message="tns:MyMessage" />
>>           <wsdl:output message="tns:AnotherMessage" />
>>         </wsdl:operation>
>>
>>     Unfortunately I cannot attach the wsdl file because it is private
>>     and protected by copyright.
>>     This is a limitation we have so far.
>>
>>
>>
>>
>>     --------------------------------------------------------------
>>     Claudio Guidi Ph.D.
>>     italianaSoftware s.r.l.
>>     via Coralli, 66 - 40026 Imola (BO), Italy
>>     http://www.italianasoftware.com/
>>     http://www.jolie-lang.org <http://www.jolie-lang.org/>
>>     Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>>     Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>>     Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>>
>>     --------------------------------------------------------------
>>
>>     Nota di riservatezza: Il presente messaggio, corredato dei
>>     relativi allegati, contiene informazioni da considerarsi
>>     strettamente riservate, ed è destinato esclusivamente al
>>     destinatario sopra indicato, il quale è l'unico autorizzato ad
>>     usarlo, copiarlo e, sotto la propria responsabilità,diffonderlo.
>>     Chiunque ricevesse questo messaggio per errore o comunque
>>     lo leggesse senza esserne legittimato è avvertito che trattenerlo,
>>     copiarlo,divulgarlo, distribuirlo a persone diverse dal
>>     destinatario è severamente proibito, ed è pregato di rinviarlo
>>     immediatamente al mittente distruggendone l'originale.
>>
>>     Grazie per la collaborazione.
>>
>>
>>     2013/12/10 Fabrizio Montesi <fam...@gm...
>>     <mailto:fam...@gm...>>
>>
>>
>>         That'd be great. We should also think about adding them to the
>>         test suite somehow..
>>
>>         Sent from my phone.
>>
>>         On Dec 10, 2013 8:12 PM, "Claudio Guidi"
>>         <cg...@it...
>>         <mailto:cg...@it...>> wrote:
>>
>>             If you give me some days I'll try to check the code with
>>             some complex wsdl.
>>
>>             Il 10/dic/2013 20:00 "Fabrizio Montesi"
>>             <fam...@gm... <mailto:fam...@gm...>> ha scritto:
>>
>>
>>                 Claudio, do you have an example for raising that error?
>>
>>                 - Fabrizio
>>
>>                 On Tue, Dec 10, 2013 at 7:07 PM, Matthias Dieter Wallnöfer
>>                 <mwa...@ya... <mailto:mwa...@ya...>>
>>
>>                 wrote:
>>                 > We should try to understand where and why the
>>                 generation of
>>                 >>
>>                 >> type undefined:undefined
>>                 >
>>                 > happened.
>>                 >
>>                 > Just to make sure - I did not get it in my case
>>                 (when un-commenting this
>>                 > particular codeline).
>>                 >
>>                 > Matthias
>>                 >
>>                 > Fabrizio Montesi schrieb:
>>                 >
>>                 >> No, I mean that your type should be generated:
>>                 >>
>>                 >> type GetWeatherInformation:undefined
>>                 >>
>>                 >> whereas the following should not be generated:
>>                 >>
>>                 >> type undefined:undefined
>>                 >>
>>                 >>
>>                 >> by implementing some check on the name of the type
>>                 we are generating,
>>                 >> to avoid redefining undefined. The latter is our
>>                 main problem
>>                 >> (@Claudio: right?).
>>                 >>
>>                 >>
>>                 >>
>>                 >> Ciao,
>>                 >> Fabrizio.
>>                 >>
>>                 >> On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter
>>                 Wallnöfer
>>                 >> <mwa...@ya...
>>                 <mailto:mwa...@ya...>> wrote:
>>                 >>>
>>                 >>> Hi Fabrizio,
>>                 >>>
>>                 >>> did I get your point?
>>                 >>>
>>                 >>> You think that declarations as
>>                 >>>>
>>                 >>>> type GetWeatherInformation:undefined
>>                 >>>
>>                 >>> should be omitted and all "GetWeatherInformation"
>>                 appearances immediately
>>                 >>> be
>>                 >>> substituted by "undefined"?
>>                 >>>
>>                 >>> Btw. in the WSDL file it is declared like this
>>                 >>> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>>                 >>>
>>                 >>>> <s:element
>>                 name="GetWeatherInformation"><s:complexType/></s:element>
>>                 >>>
>>                 >>> So to be honest I do not see an issue to include
>>                 it in Jolie's header as
>>                 >>> well. The right thing would be to change the
>>                 webservice to not include
>>                 >>> empty
>>                 >>> complex types!
>>                 >>>
>>                 >>> Matthias
>>                 >>>
>>                 >>> Fabrizio Montesi schrieb:
>>                 >>>
>>                 >>>> Mmh... a possible solution could be that we add a
>>                 check that verifies
>>                 >>>> whether we're creating a type with the same name
>>                 of a predefined type
>>                 >>>> in Jolie (in which case we should not create the
>>                 type) or not (in
>>                 >>>> which case we should create the type).
>>                 >>>>
>>                 >>>> What do you think?
>>                 >>>>
>>                 >>>> If this can work, the systematic way of doing it
>>                 would be to have some
>>                 >>>> constant set or enum defined somewhere which
>>                 contains the names of all
>>                 >>>> predefined types (I think we can reuse some
>>                 predefined map from the
>>                 >>>> parser).
>>                 >>>>
>>                 >>>> - Fabrizio
>>                 >>>>
>>                 >>>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter
>>                 Wallnöfer
>>                 >>>> <mwa...@ya...
>>                 <mailto:mwa...@ya...>> wrote:
>>                 >>>>>
>>                 >>>>> Hi all,
>>                 >>>>>
>>                 >>>>> not really correct. It generates types like
>>                 "type <name>:undefined",
>>                 >>>>> for
>>                 >>>>> instance in my case:
>>                 >>>>>>
>>                 >>>>>> type GetWeatherInformation:undefined
>>                 >>>>>
>>                 >>>>> So this is required in some cases.
>>                 >>>>>
>>                 >>>>> Cheers,
>>                 >>>>> Matthias
>>                 >>>>>
>>                 >>>>> Claudio Guidi schrieb:
>>                 >>>>>>
>>                 >>>>>> Hi all,
>>                 >>>>>>
>>                 >>>>>> sorry for the delay.
>>                 >>>>>>
>>                 >>>>>> Do you mean this line?
>>                 >>>>>>
>>                 >>>>>> jolieTypes.add( createAnyOrUndefined(
>>                 element.getName(), complexType )
>>                 >>>>>> );
>>                 >>>>>>
>>                 >>>>>> If I remember well it was commented because,
>>                 otherwise, you will find
>>                 >>>>>>
>>                 >>>>>> type undefined: undefined
>>                 >>>>>>
>>                 >>>>>> into the generated interface.
>>                 >>>>>>
>>                 >>>>>>
>>                 >>>>>>
>>                 >>>>>>
>>
>> --------------------------------------------------------------
>>                 >>>>>> Claudio Guidi Ph.D.
>>                 >>>>>> italianaSoftware s.r.l.
>>                 >>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>>                 >>>>>> http://www.italianasoftware.com/
>>                 >>>>>> http://www.jolie-lang.org
>>                 <http://www.jolie-lang.org/>
>>                 >>>>>>
>>                 >>>>>> Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>>                 >>>>>> Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>>                 >>>>>> Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>>
>>                 >>>>>>
>>
>> --------------------------------------------------------------
>>                 >>>>>>
>>                 >>>>>> Nota di riservatezza: Il presente messaggio,
>>                 corredato dei relativi
>>                 >>>>>> allegati, contiene informazioni da considerarsi
>>                 strettamente
>>                 >>>>>> riservate,
>>                 >>>>>> ed è
>>                 >>>>>> destinato esclusivamente al destinatario sopra
>>                 indicato, il quale è
>>                 >>>>>> l'unico
>>                 >>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>>                 >>>>>> responsabilità,diffonderlo. Chiunque ricevesse
>>                 questo messaggio per
>>                 >>>>>> errore o
>>                 >>>>>> comunque lo leggesse senza esserne legittimato
>>                 è avvertito che
>>                 >>>>>> trattenerlo,
>>                 >>>>>> copiarlo,divulgarlo, distribuirlo a persone
>>                 diverse dal destinatario è
>>                 >>>>>> severamente proibito, ed è pregato di rinviarlo
>>                 immediatamente al
>>                 >>>>>> mittente
>>                 >>>>>> distruggendone l'originale.
>>                 >>>>>>
>>                 >>>>>> Grazie per la collaborazione.
>>                 >>>>>>
>>                 >>>>>>
>>                 >>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>>                 <mailto:fam...@gm...>
>>                 >>>>>> <mailto:fam...@gm...
>>
>>                 <mailto:fam...@gm...>>>
>>                 >>>>>>
>>                 >>>>>>
>>                 >>>>>>       Hi all,
>>                 >>>>>>
>>                 >>>>>> @Claudio: do you have any info on that line?
>>                 >>>>>>
>>                 >>>>>>       Cheers,
>>                 >>>>>> Fabrizio.
>>                 >>>>>>
>>                 >>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias
>>                 Dieter Wallnöfer
>>                 >>>>>>       <mwa...@ya...
>>                 <mailto:mwa...@ya...>
>>                 <mailto:mwa...@ya...
>>
>>                 <mailto:mwa...@ya...>>> wrote:
>>                 >>>>>>       > Any news on this one (and also on the
>>                 Exception thing: Re:
>>                 >>>>>> [Jolie-devel]
>>                 >>>>>>       > OneWay messages)?
>>                 >>>>>>       >
>>                 >>>>>>       > Matthias
>>                 >>>>>>       >
>>                 >>>>>>       > Fabrizio Montesi schrieb:
>>                 >>>>>>       >
>>                 >>>>>> >> Hi all,
>>                 >>>>>> >> I'm trying to see why that line has been
>>                 commented...
>>                 >>>>>> especially since
>>                 >>>>>> >> it has been commented without leaving any
>>                 other comment
>>                 >>>>>> explaining the
>>                 >>>>>> >> reason in the code. Claudio, any memories? :-)
>>                 >>>>>> >>
>>                 >>>>>> >> I see it's commented out in many parts of
>>                 the code.
>>                 >>>>>> >>
>>                 >>>>>> >>
>>                 >>>>>> >> Cheers,
>>                 >>>>>> >> Fabrizio.
>>                 >>>>>>       >
>>                 >>>>>>       >
>>                 >>>>>>
>>                 >>>>>>
>>                 >
>>
>>
>>
>

Re: [Jolie-devel] wsdl2jolie patches

[Matthias D. W. <mwa...@ya...>]

Hi Claudio,

that's fine, please apply :-).

Matthias

Claudio Guidi schrieb:
> Hi Matthias,
>
> I made some tests and I would patch your patch :-) with the following 
> code:
>
> if ( (particle = contentType.asParticle()) == null && 
> !checkSkippedTypes( element.getName(), element.getTargetNamespace() )) {
>                     jolieTypes.add( createAnyOrUndefined( 
> element.getName(), complexType ) );
>                     continue;
>                 }
>
> I added   && !checkSkippedTypes( element.getName(), 
> element.getTargetNamespace() ) which avoid to process basic element types.
>
> So, Matthias could apply the patch with my modifications?
>
> --------------------------------------------------------------
> Claudio Guidi Ph.D.
> italianaSoftware s.r.l.
> via Coralli, 66 - 40026 Imola (BO), Italy
> http://www.italianasoftware.com/
> http://www.jolie-lang.org <http://www.jolie-lang.org/>
> Phone: +39 0542 788201
> Mobile: +39 347 0694065
> Fax: +39 0542 628048
> --------------------------------------------------------------
>
> Nota di riservatezza: Il presente messaggio, corredato dei 
> relativi allegati, contiene informazioni da considerarsi strettamente 
> riservate, ed è destinato esclusivamente al destinatario sopra 
> indicato, il quale è l'unico autorizzato ad usarlo, copiarlo e, sotto 
> la propria responsabilità,diffonderlo. Chiunque ricevesse questo 
> messaggio per errore o comunque lo leggesse senza esserne legittimato 
> è avvertito che trattenerlo, copiarlo,divulgarlo, distribuirlo a 
> persone diverse dal destinatario è severamente proibito, ed è pregato 
> di rinviarlo immediatamente al mittente distruggendone l'originale.
>
> Grazie per la collaborazione.
>
>
> 2013/12/12 Claudio Guidi <cg...@it... 
> <mailto:cg...@it...>>
>
>     Hi guys,
>
>     I made some tests with a more complex wsdl. In the following what
>     I found:
>
>     1) if a insert the line that Matthias has commented
>     (jolieTypes.add( createAnyOrUndefined( element.getName(),
>     complexType ) );) in the final interface I will found basic types
>     declarations such as
>
>     type boolean:undefined
>     type string:undefined
>
>     So far it is not clear to me when exactly happens. I need more
>     time for investigating.
>
>     Thus, I think we need more test before enabling the patch.
>
>
>     new issues!!!
>     2) XSOMParser seems to not process import tags where
>     schemaLocation is not defined. Ex:
>     <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/">
>
>     if you change the line into:
>     <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/"
>     schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
>     it wroks.
>
>     But this is quite annoying because if the wsdl is generated (as in
>     my case) without schemaLocation you always need to download the
>     file,add schemaLocation attributes to all the imports and then
>     launch the wsdl2jolie locally. It's a nightmare!
>     I tried to google the problem but I didn't find anything useful,
>     could you help me to find some fixes? Maybe we need to update the
>     XSOM library?
>
>     3) at the present, if the message of an operation contains more
>     than one part, the conversion could fail. Ex:
>
>     <s:schema targetNamespace="blablabla">
>           <s:import
>     namespace="http://schemas.xmlsoap.org/soap/encoding/"
>     schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
>           <s:complexType name="HomerSimpsons">
>             some complex content
>             </s:complexContent>
>           </s:complexType>
>         </s:schema>
>
>       <wsdl:message name="MYMessage">
>         <wsdl:part name="part1" type="s:string" />
>         <wsdl:part name="part2" type="s1:HomerSimpsons" />
>       </wsdl:message>
>
>     <wsdl:operation name="operationName">
>           <wsdl:input message="tns:MyMessage" />
>           <wsdl:output message="tns:AnotherMessage" />
>         </wsdl:operation>
>
>     Unfortunately I cannot attach the wsdl file because it is private
>     and protected by copyright.
>     This is a limitation we have so far.
>
>
>
>
>     --------------------------------------------------------------
>     Claudio Guidi Ph.D.
>     italianaSoftware s.r.l.
>     via Coralli, 66 - 40026 Imola (BO), Italy
>     http://www.italianasoftware.com/
>     http://www.jolie-lang.org <http://www.jolie-lang.org/>
>     Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>     Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>     Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>     --------------------------------------------------------------
>
>     Nota di riservatezza: Il presente messaggio, corredato dei
>     relativi allegati, contiene informazioni da considerarsi
>     strettamente riservate, ed è destinato esclusivamente al
>     destinatario sopra indicato, il quale è l'unico autorizzato ad
>     usarlo, copiarlo e, sotto la propria responsabilità,diffonderlo.
>     Chiunque ricevesse questo messaggio per errore o comunque
>     lo leggesse senza esserne legittimato è avvertito che trattenerlo,
>     copiarlo,divulgarlo, distribuirlo a persone diverse dal
>     destinatario è severamente proibito, ed è pregato di rinviarlo
>     immediatamente al mittente distruggendone l'originale.
>
>     Grazie per la collaborazione.
>
>
>     2013/12/10 Fabrizio Montesi <fam...@gm...
>     <mailto:fam...@gm...>>
>
>         That'd be great. We should also think about adding them to the
>         test suite somehow..
>
>         Sent from my phone.
>
>         On Dec 10, 2013 8:12 PM, "Claudio Guidi"
>         <cg...@it...
>         <mailto:cg...@it...>> wrote:
>
>             If you give me some days I'll try to check the code with
>             some complex wsdl.
>
>             Il 10/dic/2013 20:00 "Fabrizio Montesi"
>             <fam...@gm... <mailto:fam...@gm...>> ha scritto:
>
>                 Claudio, do you have an example for raising that error?
>
>                 - Fabrizio
>
>                 On Tue, Dec 10, 2013 at 7:07 PM, Matthias Dieter Wallnöfer
>                 <mwa...@ya... <mailto:mwa...@ya...>>
>                 wrote:
>                 > We should try to understand where and why the
>                 generation of
>                 >>
>                 >> type undefined:undefined
>                 >
>                 > happened.
>                 >
>                 > Just to make sure - I did not get it in my case
>                 (when un-commenting this
>                 > particular codeline).
>                 >
>                 > Matthias
>                 >
>                 > Fabrizio Montesi schrieb:
>                 >
>                 >> No, I mean that your type should be generated:
>                 >>
>                 >> type GetWeatherInformation:undefined
>                 >>
>                 >> whereas the following should not be generated:
>                 >>
>                 >> type undefined:undefined
>                 >>
>                 >>
>                 >> by implementing some check on the name of the type
>                 we are generating,
>                 >> to avoid redefining undefined. The latter is our
>                 main problem
>                 >> (@Claudio: right?).
>                 >>
>                 >>
>                 >>
>                 >> Ciao,
>                 >> Fabrizio.
>                 >>
>                 >> On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter
>                 Wallnöfer
>                 >> <mwa...@ya...
>                 <mailto:mwa...@ya...>> wrote:
>                 >>>
>                 >>> Hi Fabrizio,
>                 >>>
>                 >>> did I get your point?
>                 >>>
>                 >>> You think that declarations as
>                 >>>>
>                 >>>> type GetWeatherInformation:undefined
>                 >>>
>                 >>> should be omitted and all "GetWeatherInformation"
>                 appearances immediately
>                 >>> be
>                 >>> substituted by "undefined"?
>                 >>>
>                 >>> Btw. in the WSDL file it is declared like this
>                 >>> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>                 >>>
>                 >>>> <s:element
>                 name="GetWeatherInformation"><s:complexType/></s:element>
>                 >>>
>                 >>> So to be honest I do not see an issue to include
>                 it in Jolie's header as
>                 >>> well. The right thing would be to change the
>                 webservice to not include
>                 >>> empty
>                 >>> complex types!
>                 >>>
>                 >>> Matthias
>                 >>>
>                 >>> Fabrizio Montesi schrieb:
>                 >>>
>                 >>>> Mmh... a possible solution could be that we add a
>                 check that verifies
>                 >>>> whether we're creating a type with the same name
>                 of a predefined type
>                 >>>> in Jolie (in which case we should not create the
>                 type) or not (in
>                 >>>> which case we should create the type).
>                 >>>>
>                 >>>> What do you think?
>                 >>>>
>                 >>>> If this can work, the systematic way of doing it
>                 would be to have some
>                 >>>> constant set or enum defined somewhere which
>                 contains the names of all
>                 >>>> predefined types (I think we can reuse some
>                 predefined map from the
>                 >>>> parser).
>                 >>>>
>                 >>>> - Fabrizio
>                 >>>>
>                 >>>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter
>                 Wallnöfer
>                 >>>> <mwa...@ya...
>                 <mailto:mwa...@ya...>> wrote:
>                 >>>>>
>                 >>>>> Hi all,
>                 >>>>>
>                 >>>>> not really correct. It generates types like
>                 "type <name>:undefined",
>                 >>>>> for
>                 >>>>> instance in my case:
>                 >>>>>>
>                 >>>>>> type GetWeatherInformation:undefined
>                 >>>>>
>                 >>>>> So this is required in some cases.
>                 >>>>>
>                 >>>>> Cheers,
>                 >>>>> Matthias
>                 >>>>>
>                 >>>>> Claudio Guidi schrieb:
>                 >>>>>>
>                 >>>>>> Hi all,
>                 >>>>>>
>                 >>>>>> sorry for the delay.
>                 >>>>>>
>                 >>>>>> Do you mean this line?
>                 >>>>>>
>                 >>>>>> jolieTypes.add( createAnyOrUndefined(
>                 element.getName(), complexType )
>                 >>>>>> );
>                 >>>>>>
>                 >>>>>> If I remember well it was commented because,
>                 otherwise, you will find
>                 >>>>>>
>                 >>>>>> type undefined: undefined
>                 >>>>>>
>                 >>>>>> into the generated interface.
>                 >>>>>>
>                 >>>>>>
>                 >>>>>>
>                 >>>>>>
>                 --------------------------------------------------------------
>                 >>>>>> Claudio Guidi Ph.D.
>                 >>>>>> italianaSoftware s.r.l.
>                 >>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>                 >>>>>> http://www.italianasoftware.com/
>                 >>>>>> http://www.jolie-lang.org
>                 <http://www.jolie-lang.org/>
>                 >>>>>>
>                 >>>>>> Phone: +39 0542 788201 <tel:%2B39%200542%20788201>
>                 >>>>>> Mobile: +39 347 0694065 <tel:%2B39%20347%200694065>
>                 >>>>>> Fax: +39 0542 628048 <tel:%2B39%200542%20628048>
>                 >>>>>>
>                 --------------------------------------------------------------
>                 >>>>>>
>                 >>>>>> Nota di riservatezza: Il presente messaggio,
>                 corredato dei relativi
>                 >>>>>> allegati, contiene informazioni da considerarsi
>                 strettamente
>                 >>>>>> riservate,
>                 >>>>>> ed è
>                 >>>>>> destinato esclusivamente al destinatario sopra
>                 indicato, il quale è
>                 >>>>>> l'unico
>                 >>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>                 >>>>>> responsabilità,diffonderlo. Chiunque ricevesse
>                 questo messaggio per
>                 >>>>>> errore o
>                 >>>>>> comunque lo leggesse senza esserne legittimato
>                 è avvertito che
>                 >>>>>> trattenerlo,
>                 >>>>>> copiarlo,divulgarlo, distribuirlo a persone
>                 diverse dal destinatario è
>                 >>>>>> severamente proibito, ed è pregato di rinviarlo
>                 immediatamente al
>                 >>>>>> mittente
>                 >>>>>> distruggendone l'originale.
>                 >>>>>>
>                 >>>>>> Grazie per la collaborazione.
>                 >>>>>>
>                 >>>>>>
>                 >>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>                 <mailto:fam...@gm...>
>                 >>>>>> <mailto:fam...@gm...
>                 <mailto:fam...@gm...>>>
>                 >>>>>>
>                 >>>>>>
>                 >>>>>>       Hi all,
>                 >>>>>>
>                 >>>>>> @Claudio: do you have any info on that line?
>                 >>>>>>
>                 >>>>>>       Cheers,
>                 >>>>>> Fabrizio.
>                 >>>>>>
>                 >>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias
>                 Dieter Wallnöfer
>                 >>>>>>       <mwa...@ya...
>                 <mailto:mwa...@ya...>
>                 <mailto:mwa...@ya...
>                 <mailto:mwa...@ya...>>> wrote:
>                 >>>>>>       > Any news on this one (and also on the
>                 Exception thing: Re:
>                 >>>>>> [Jolie-devel]
>                 >>>>>>       > OneWay messages)?
>                 >>>>>>       >
>                 >>>>>>       > Matthias
>                 >>>>>>       >
>                 >>>>>>       > Fabrizio Montesi schrieb:
>                 >>>>>>       >
>                 >>>>>> >> Hi all,
>                 >>>>>> >> I'm trying to see why that line has been
>                 commented...
>                 >>>>>> especially since
>                 >>>>>> >> it has been commented without leaving any
>                 other comment
>                 >>>>>> explaining the
>                 >>>>>> >> reason in the code. Claudio, any memories? :-)
>                 >>>>>> >>
>                 >>>>>> >> I see it's commented out in many parts of
>                 the code.
>                 >>>>>> >>
>                 >>>>>> >>
>                 >>>>>> >> Cheers,
>                 >>>>>> >> Fabrizio.
>                 >>>>>>       >
>                 >>>>>>       >
>                 >>>>>>
>                 >>>>>>
>                 >
>
>
>

Re: [Jolie-devel] wsdl2jolie patches

[Claudio G. <cg...@it...>]

Hi guys,

I made some tests with a more complex wsdl. In the following what I found:

1) if a insert the line that Matthias has commented (jolieTypes.add(
createAnyOrUndefined( element.getName(), complexType ) );) in the final
interface I will found basic types declarations such as

type boolean:undefined
type string:undefined

So far it is not clear to me when  exactly happens. I need more time for
investigating.

Thus, I think we need more test before enabling the patch.


new issues!!!
2) XSOMParser seems to not process import tags where schemaLocation is not
defined. Ex:
<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/">

if you change the line into:
<s:import namespace="http://schemas.xmlsoap.org/soap/encoding/"
schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
it wroks.

But this is quite annoying because if the wsdl is generated (as in my case)
without schemaLocation you always need to download the file,add
schemaLocation attributes to all the imports and then launch the wsdl2jolie
locally. It's a nightmare!
I tried to google the problem but I didn't find anything useful, could you
help me to find some fixes? Maybe we need to update the XSOM library?

3) at the present, if the message of an operation contains more than one
part, the conversion could fail. Ex:

<s:schema targetNamespace="blablabla">
      <s:import namespace="http://schemas.xmlsoap.org/soap/encoding/"
schemaLocation="http://schemas.xmlsoap.org/soap/encoding/"/>
      <s:complexType name="HomerSimpsons">
        some complex content
        </s:complexContent>
      </s:complexType>
    </s:schema>

  <wsdl:message name="MYMessage">
    <wsdl:part name="part1" type="s:string" />
    <wsdl:part name="part2" type="s1:HomerSimpsons" />
  </wsdl:message>

<wsdl:operation name="operationName">
      <wsdl:input message="tns:MyMessage" />
      <wsdl:output message="tns:AnotherMessage" />
    </wsdl:operation>

Unfortunately I cannot attach the wsdl file because it is private and
protected by copyright.
This is a limitation we have so far.




--------------------------------------------------------------
Claudio Guidi Ph.D.
italianaSoftware s.r.l.
via Coralli, 66 - 40026 Imola (BO), Italy
http://www.italianasoftware.com/
http://www.jolie-lang.org
Phone: +39 0542 788201
Mobile: +39 347 0694065
Fax: +39 0542 628048
--------------------------------------------------------------

Nota di riservatezza: Il presente messaggio, corredato dei
relativi allegati, contiene informazioni da considerarsi strettamente
riservate, ed è destinato esclusivamente al destinatario sopra indicato, il
quale è l'unico autorizzato ad usarlo, copiarlo e, sotto la propria
responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore
o comunque lo leggesse senza esserne legittimato è avvertito che
trattenerlo, copiarlo,divulgarlo, distribuirlo a persone diverse dal
destinatario è severamente proibito, ed è pregato di rinviarlo
immediatamente al mittente distruggendone l'originale.

Grazie per la collaborazione.


2013/12/10 Fabrizio Montesi <fam...@gm...>

> That'd be great. We should also think about adding them to the test suite
> somehow..
>
> Sent from my phone.
> On Dec 10, 2013 8:12 PM, "Claudio Guidi" <cg...@it...>
> wrote:
>
>> If you give me some days I'll try to check the code with some complex
>> wsdl.
>> Il 10/dic/2013 20:00 "Fabrizio Montesi" <fam...@gm...> ha scritto:
>>
>>> Claudio, do you have an example for raising that error?
>>>
>>> - Fabrizio
>>>
>>> On Tue, Dec 10, 2013 at 7:07 PM, Matthias Dieter Wallnöfer
>>> <mwa...@ya...> wrote:
>>> > We should try to understand where and why the generation of
>>> >>
>>> >> type undefined:undefined
>>> >
>>> > happened.
>>> >
>>> > Just to make sure - I did not get it in my case (when un-commenting
>>> this
>>> > particular codeline).
>>> >
>>> > Matthias
>>> >
>>> > Fabrizio Montesi schrieb:
>>> >
>>> >> No, I mean that your type should be generated:
>>> >>
>>> >> type GetWeatherInformation:undefined
>>> >>
>>> >> whereas the following should not be generated:
>>> >>
>>> >> type undefined:undefined
>>> >>
>>> >>
>>> >> by implementing some check on the name of the type we are generating,
>>> >> to avoid redefining undefined. The latter is our main problem
>>> >> (@Claudio: right?).
>>> >>
>>> >>
>>> >>
>>> >> Ciao,
>>> >> Fabrizio.
>>> >>
>>> >> On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter Wallnöfer
>>> >> <mwa...@ya...> wrote:
>>> >>>
>>> >>> Hi Fabrizio,
>>> >>>
>>> >>> did I get your point?
>>> >>>
>>> >>> You think that declarations as
>>> >>>>
>>> >>>> type GetWeatherInformation:undefined
>>> >>>
>>> >>> should be omitted and all "GetWeatherInformation" appearances
>>> immediately
>>> >>> be
>>> >>> substituted by "undefined"?
>>> >>>
>>> >>> Btw. in the WSDL file it is declared like this
>>> >>> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>>> >>>
>>> >>>> <s:element name="GetWeatherInformation"><s:complexType/></s:element>
>>> >>>
>>> >>> So to be honest I do not see an issue to include it in Jolie's
>>> header as
>>> >>> well. The right thing would be to change the webservice to not
>>> include
>>> >>> empty
>>> >>> complex types!
>>> >>>
>>> >>> Matthias
>>> >>>
>>> >>> Fabrizio Montesi schrieb:
>>> >>>
>>> >>>> Mmh... a possible solution could be that we add a check that
>>> verifies
>>> >>>> whether we're creating a type with the same name of a predefined
>>> type
>>> >>>> in Jolie (in which case we should not create the type) or not (in
>>> >>>> which case we should create the type).
>>> >>>>
>>> >>>> What do you think?
>>> >>>>
>>> >>>> If this can work, the systematic way of doing it would be to have
>>> some
>>> >>>> constant set or enum defined somewhere which contains the names of
>>> all
>>> >>>> predefined types (I think we can reuse some predefined map from the
>>> >>>> parser).
>>> >>>>
>>> >>>> - Fabrizio
>>> >>>>
>>> >>>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer
>>> >>>> <mwa...@ya...> wrote:
>>> >>>>>
>>> >>>>> Hi all,
>>> >>>>>
>>> >>>>> not really correct. It generates types like "type
>>> <name>:undefined",
>>> >>>>> for
>>> >>>>> instance in my case:
>>> >>>>>>
>>> >>>>>> type GetWeatherInformation:undefined
>>> >>>>>
>>> >>>>> So this is required in some cases.
>>> >>>>>
>>> >>>>> Cheers,
>>> >>>>> Matthias
>>> >>>>>
>>> >>>>> Claudio Guidi schrieb:
>>> >>>>>>
>>> >>>>>> Hi all,
>>> >>>>>>
>>> >>>>>> sorry for the delay.
>>> >>>>>>
>>> >>>>>> Do you mean this line?
>>> >>>>>>
>>> >>>>>> jolieTypes.add( createAnyOrUndefined( element.getName(),
>>> complexType )
>>> >>>>>> );
>>> >>>>>>
>>> >>>>>> If I remember well it was commented because, otherwise, you will
>>> find
>>> >>>>>>
>>> >>>>>> type undefined: undefined
>>> >>>>>>
>>> >>>>>> into the generated interface.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> --------------------------------------------------------------
>>> >>>>>> Claudio Guidi Ph.D.
>>> >>>>>> italianaSoftware s.r.l.
>>> >>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>>> >>>>>> http://www.italianasoftware.com/
>>> >>>>>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>>> >>>>>>
>>> >>>>>> Phone: +39 0542 788201
>>> >>>>>> Mobile: +39 347 0694065
>>> >>>>>> Fax: +39 0542 628048
>>> >>>>>> --------------------------------------------------------------
>>> >>>>>>
>>> >>>>>> Nota di riservatezza: Il presente messaggio, corredato dei
>>> relativi
>>> >>>>>> allegati, contiene informazioni da considerarsi strettamente
>>> >>>>>> riservate,
>>> >>>>>> ed è
>>> >>>>>> destinato esclusivamente al destinatario sopra indicato, il quale
>>> è
>>> >>>>>> l'unico
>>> >>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>>> >>>>>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio
>>> per
>>> >>>>>> errore o
>>> >>>>>> comunque lo leggesse senza esserne legittimato è avvertito che
>>> >>>>>> trattenerlo,
>>> >>>>>> copiarlo,divulgarlo, distribuirlo a persone diverse dal
>>> destinatario è
>>> >>>>>> severamente proibito, ed è pregato di rinviarlo immediatamente al
>>> >>>>>> mittente
>>> >>>>>> distruggendone l'originale.
>>> >>>>>>
>>> >>>>>> Grazie per la collaborazione.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>>> >>>>>> <mailto:fam...@gm...>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>       Hi all,
>>> >>>>>>
>>> >>>>>>       @Claudio: do you have any info on that line?
>>> >>>>>>
>>> >>>>>>       Cheers,
>>> >>>>>>       Fabrizio.
>>> >>>>>>
>>> >>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer
>>> >>>>>>       <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>>> >>>>>>       > Any news on this one (and also on the Exception thing: Re:
>>> >>>>>>       [Jolie-devel]
>>> >>>>>>       > OneWay messages)?
>>> >>>>>>       >
>>> >>>>>>       > Matthias
>>> >>>>>>       >
>>> >>>>>>       > Fabrizio Montesi schrieb:
>>> >>>>>>       >
>>> >>>>>>       >> Hi all,
>>> >>>>>>       >> I'm trying to see why that line has been commented...
>>> >>>>>>       especially since
>>> >>>>>>       >> it has been commented without leaving any other comment
>>> >>>>>>       explaining the
>>> >>>>>>       >> reason in the code. Claudio, any memories? :-)
>>> >>>>>>       >>
>>> >>>>>>       >> I see it's commented out in many parts of the code.
>>> >>>>>>       >>
>>> >>>>>>       >>
>>> >>>>>>       >> Cheers,
>>> >>>>>>       >> Fabrizio.
>>> >>>>>>       >
>>> >>>>>>       >
>>> >>>>>>
>>> >>>>>>
>>> >
>>>
>>

Re: [Jolie-devel] wsdl2jolie patches

[Fabrizio M. <fam...@gm...>]

That'd be great. We should also think about adding them to the test suite
somehow..

Sent from my phone.
On Dec 10, 2013 8:12 PM, "Claudio Guidi" <cg...@it...>
wrote:

> If you give me some days I'll try to check the code with some complex wsdl.
> Il 10/dic/2013 20:00 "Fabrizio Montesi" <fam...@gm...> ha scritto:
>
>> Claudio, do you have an example for raising that error?
>>
>> - Fabrizio
>>
>> On Tue, Dec 10, 2013 at 7:07 PM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>> > We should try to understand where and why the generation of
>> >>
>> >> type undefined:undefined
>> >
>> > happened.
>> >
>> > Just to make sure - I did not get it in my case (when un-commenting this
>> > particular codeline).
>> >
>> > Matthias
>> >
>> > Fabrizio Montesi schrieb:
>> >
>> >> No, I mean that your type should be generated:
>> >>
>> >> type GetWeatherInformation:undefined
>> >>
>> >> whereas the following should not be generated:
>> >>
>> >> type undefined:undefined
>> >>
>> >>
>> >> by implementing some check on the name of the type we are generating,
>> >> to avoid redefining undefined. The latter is our main problem
>> >> (@Claudio: right?).
>> >>
>> >>
>> >>
>> >> Ciao,
>> >> Fabrizio.
>> >>
>> >> On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter Wallnöfer
>> >> <mwa...@ya...> wrote:
>> >>>
>> >>> Hi Fabrizio,
>> >>>
>> >>> did I get your point?
>> >>>
>> >>> You think that declarations as
>> >>>>
>> >>>> type GetWeatherInformation:undefined
>> >>>
>> >>> should be omitted and all "GetWeatherInformation" appearances
>> immediately
>> >>> be
>> >>> substituted by "undefined"?
>> >>>
>> >>> Btw. in the WSDL file it is declared like this
>> >>> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>> >>>
>> >>>> <s:element name="GetWeatherInformation"><s:complexType/></s:element>
>> >>>
>> >>> So to be honest I do not see an issue to include it in Jolie's header
>> as
>> >>> well. The right thing would be to change the webservice to not include
>> >>> empty
>> >>> complex types!
>> >>>
>> >>> Matthias
>> >>>
>> >>> Fabrizio Montesi schrieb:
>> >>>
>> >>>> Mmh... a possible solution could be that we add a check that verifies
>> >>>> whether we're creating a type with the same name of a predefined type
>> >>>> in Jolie (in which case we should not create the type) or not (in
>> >>>> which case we should create the type).
>> >>>>
>> >>>> What do you think?
>> >>>>
>> >>>> If this can work, the systematic way of doing it would be to have
>> some
>> >>>> constant set or enum defined somewhere which contains the names of
>> all
>> >>>> predefined types (I think we can reuse some predefined map from the
>> >>>> parser).
>> >>>>
>> >>>> - Fabrizio
>> >>>>
>> >>>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer
>> >>>> <mwa...@ya...> wrote:
>> >>>>>
>> >>>>> Hi all,
>> >>>>>
>> >>>>> not really correct. It generates types like "type <name>:undefined",
>> >>>>> for
>> >>>>> instance in my case:
>> >>>>>>
>> >>>>>> type GetWeatherInformation:undefined
>> >>>>>
>> >>>>> So this is required in some cases.
>> >>>>>
>> >>>>> Cheers,
>> >>>>> Matthias
>> >>>>>
>> >>>>> Claudio Guidi schrieb:
>> >>>>>>
>> >>>>>> Hi all,
>> >>>>>>
>> >>>>>> sorry for the delay.
>> >>>>>>
>> >>>>>> Do you mean this line?
>> >>>>>>
>> >>>>>> jolieTypes.add( createAnyOrUndefined( element.getName(),
>> complexType )
>> >>>>>> );
>> >>>>>>
>> >>>>>> If I remember well it was commented because, otherwise, you will
>> find
>> >>>>>>
>> >>>>>> type undefined: undefined
>> >>>>>>
>> >>>>>> into the generated interface.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --------------------------------------------------------------
>> >>>>>> Claudio Guidi Ph.D.
>> >>>>>> italianaSoftware s.r.l.
>> >>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>> >>>>>> http://www.italianasoftware.com/
>> >>>>>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>> >>>>>>
>> >>>>>> Phone: +39 0542 788201
>> >>>>>> Mobile: +39 347 0694065
>> >>>>>> Fax: +39 0542 628048
>> >>>>>> --------------------------------------------------------------
>> >>>>>>
>> >>>>>> Nota di riservatezza: Il presente messaggio, corredato dei relativi
>> >>>>>> allegati, contiene informazioni da considerarsi strettamente
>> >>>>>> riservate,
>> >>>>>> ed è
>> >>>>>> destinato esclusivamente al destinatario sopra indicato, il quale è
>> >>>>>> l'unico
>> >>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>> >>>>>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per
>> >>>>>> errore o
>> >>>>>> comunque lo leggesse senza esserne legittimato è avvertito che
>> >>>>>> trattenerlo,
>> >>>>>> copiarlo,divulgarlo, distribuirlo a persone diverse dal
>> destinatario è
>> >>>>>> severamente proibito, ed è pregato di rinviarlo immediatamente al
>> >>>>>> mittente
>> >>>>>> distruggendone l'originale.
>> >>>>>>
>> >>>>>> Grazie per la collaborazione.
>> >>>>>>
>> >>>>>>
>> >>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>> >>>>>> <mailto:fam...@gm...>>
>> >>>>>>
>> >>>>>>
>> >>>>>>       Hi all,
>> >>>>>>
>> >>>>>>       @Claudio: do you have any info on that line?
>> >>>>>>
>> >>>>>>       Cheers,
>> >>>>>>       Fabrizio.
>> >>>>>>
>> >>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer
>> >>>>>>       <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>> >>>>>>       > Any news on this one (and also on the Exception thing: Re:
>> >>>>>>       [Jolie-devel]
>> >>>>>>       > OneWay messages)?
>> >>>>>>       >
>> >>>>>>       > Matthias
>> >>>>>>       >
>> >>>>>>       > Fabrizio Montesi schrieb:
>> >>>>>>       >
>> >>>>>>       >> Hi all,
>> >>>>>>       >> I'm trying to see why that line has been commented...
>> >>>>>>       especially since
>> >>>>>>       >> it has been commented without leaving any other comment
>> >>>>>>       explaining the
>> >>>>>>       >> reason in the code. Claudio, any memories? :-)
>> >>>>>>       >>
>> >>>>>>       >> I see it's commented out in many parts of the code.
>> >>>>>>       >>
>> >>>>>>       >>
>> >>>>>>       >> Cheers,
>> >>>>>>       >> Fabrizio.
>> >>>>>>       >
>> >>>>>>       >
>> >>>>>>
>> >>>>>>
>> >
>>
>

Re: [Jolie-devel] wsdl2jolie patches

[Claudio G. <cg...@it...>]

If you give me some days I'll try to check the code with some complex wsdl.
Il 10/dic/2013 20:00 "Fabrizio Montesi" <fam...@gm...> ha scritto:

> Claudio, do you have an example for raising that error?
>
> - Fabrizio
>
> On Tue, Dec 10, 2013 at 7:07 PM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
> > We should try to understand where and why the generation of
> >>
> >> type undefined:undefined
> >
> > happened.
> >
> > Just to make sure - I did not get it in my case (when un-commenting this
> > particular codeline).
> >
> > Matthias
> >
> > Fabrizio Montesi schrieb:
> >
> >> No, I mean that your type should be generated:
> >>
> >> type GetWeatherInformation:undefined
> >>
> >> whereas the following should not be generated:
> >>
> >> type undefined:undefined
> >>
> >>
> >> by implementing some check on the name of the type we are generating,
> >> to avoid redefining undefined. The latter is our main problem
> >> (@Claudio: right?).
> >>
> >>
> >>
> >> Ciao,
> >> Fabrizio.
> >>
> >> On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter Wallnöfer
> >> <mwa...@ya...> wrote:
> >>>
> >>> Hi Fabrizio,
> >>>
> >>> did I get your point?
> >>>
> >>> You think that declarations as
> >>>>
> >>>> type GetWeatherInformation:undefined
> >>>
> >>> should be omitted and all "GetWeatherInformation" appearances
> immediately
> >>> be
> >>> substituted by "undefined"?
> >>>
> >>> Btw. in the WSDL file it is declared like this
> >>> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
> >>>
> >>>> <s:element name="GetWeatherInformation"><s:complexType/></s:element>
> >>>
> >>> So to be honest I do not see an issue to include it in Jolie's header
> as
> >>> well. The right thing would be to change the webservice to not include
> >>> empty
> >>> complex types!
> >>>
> >>> Matthias
> >>>
> >>> Fabrizio Montesi schrieb:
> >>>
> >>>> Mmh... a possible solution could be that we add a check that verifies
> >>>> whether we're creating a type with the same name of a predefined type
> >>>> in Jolie (in which case we should not create the type) or not (in
> >>>> which case we should create the type).
> >>>>
> >>>> What do you think?
> >>>>
> >>>> If this can work, the systematic way of doing it would be to have some
> >>>> constant set or enum defined somewhere which contains the names of all
> >>>> predefined types (I think we can reuse some predefined map from the
> >>>> parser).
> >>>>
> >>>> - Fabrizio
> >>>>
> >>>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer
> >>>> <mwa...@ya...> wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> not really correct. It generates types like "type <name>:undefined",
> >>>>> for
> >>>>> instance in my case:
> >>>>>>
> >>>>>> type GetWeatherInformation:undefined
> >>>>>
> >>>>> So this is required in some cases.
> >>>>>
> >>>>> Cheers,
> >>>>> Matthias
> >>>>>
> >>>>> Claudio Guidi schrieb:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> sorry for the delay.
> >>>>>>
> >>>>>> Do you mean this line?
> >>>>>>
> >>>>>> jolieTypes.add( createAnyOrUndefined( element.getName(),
> complexType )
> >>>>>> );
> >>>>>>
> >>>>>> If I remember well it was commented because, otherwise, you will
> find
> >>>>>>
> >>>>>> type undefined: undefined
> >>>>>>
> >>>>>> into the generated interface.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --------------------------------------------------------------
> >>>>>> Claudio Guidi Ph.D.
> >>>>>> italianaSoftware s.r.l.
> >>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
> >>>>>> http://www.italianasoftware.com/
> >>>>>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
> >>>>>>
> >>>>>> Phone: +39 0542 788201
> >>>>>> Mobile: +39 347 0694065
> >>>>>> Fax: +39 0542 628048
> >>>>>> --------------------------------------------------------------
> >>>>>>
> >>>>>> Nota di riservatezza: Il presente messaggio, corredato dei relativi
> >>>>>> allegati, contiene informazioni da considerarsi strettamente
> >>>>>> riservate,
> >>>>>> ed è
> >>>>>> destinato esclusivamente al destinatario sopra indicato, il quale è
> >>>>>> l'unico
> >>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
> >>>>>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per
> >>>>>> errore o
> >>>>>> comunque lo leggesse senza esserne legittimato è avvertito che
> >>>>>> trattenerlo,
> >>>>>> copiarlo,divulgarlo, distribuirlo a persone diverse dal
> destinatario è
> >>>>>> severamente proibito, ed è pregato di rinviarlo immediatamente al
> >>>>>> mittente
> >>>>>> distruggendone l'originale.
> >>>>>>
> >>>>>> Grazie per la collaborazione.
> >>>>>>
> >>>>>>
> >>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
> >>>>>> <mailto:fam...@gm...>>
> >>>>>>
> >>>>>>
> >>>>>>       Hi all,
> >>>>>>
> >>>>>>       @Claudio: do you have any info on that line?
> >>>>>>
> >>>>>>       Cheers,
> >>>>>>       Fabrizio.
> >>>>>>
> >>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer
> >>>>>>       <mwa...@ya... <mailto:mwa...@ya...>> wrote:
> >>>>>>       > Any news on this one (and also on the Exception thing: Re:
> >>>>>>       [Jolie-devel]
> >>>>>>       > OneWay messages)?
> >>>>>>       >
> >>>>>>       > Matthias
> >>>>>>       >
> >>>>>>       > Fabrizio Montesi schrieb:
> >>>>>>       >
> >>>>>>       >> Hi all,
> >>>>>>       >> I'm trying to see why that line has been commented...
> >>>>>>       especially since
> >>>>>>       >> it has been commented without leaving any other comment
> >>>>>>       explaining the
> >>>>>>       >> reason in the code. Claudio, any memories? :-)
> >>>>>>       >>
> >>>>>>       >> I see it's commented out in many parts of the code.
> >>>>>>       >>
> >>>>>>       >>
> >>>>>>       >> Cheers,
> >>>>>>       >> Fabrizio.
> >>>>>>       >
> >>>>>>       >
> >>>>>>
> >>>>>>
> >
>

Re: [Jolie-devel] wsdl2jolie patches

[Fabrizio M. <fam...@gm...>]

Claudio, do you have an example for raising that error?

- Fabrizio

On Tue, Dec 10, 2013 at 7:07 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> We should try to understand where and why the generation of
>>
>> type undefined:undefined
>
> happened.
>
> Just to make sure - I did not get it in my case (when un-commenting this
> particular codeline).
>
> Matthias
>
> Fabrizio Montesi schrieb:
>
>> No, I mean that your type should be generated:
>>
>> type GetWeatherInformation:undefined
>>
>> whereas the following should not be generated:
>>
>> type undefined:undefined
>>
>>
>> by implementing some check on the name of the type we are generating,
>> to avoid redefining undefined. The latter is our main problem
>> (@Claudio: right?).
>>
>>
>>
>> Ciao,
>> Fabrizio.
>>
>> On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>>
>>> Hi Fabrizio,
>>>
>>> did I get your point?
>>>
>>> You think that declarations as
>>>>
>>>> type GetWeatherInformation:undefined
>>>
>>> should be omitted and all "GetWeatherInformation" appearances immediately
>>> be
>>> substituted by "undefined"?
>>>
>>> Btw. in the WSDL file it is declared like this
>>> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>>>
>>>> <s:element name="GetWeatherInformation"><s:complexType/></s:element>
>>>
>>> So to be honest I do not see an issue to include it in Jolie's header as
>>> well. The right thing would be to change the webservice to not include
>>> empty
>>> complex types!
>>>
>>> Matthias
>>>
>>> Fabrizio Montesi schrieb:
>>>
>>>> Mmh... a possible solution could be that we add a check that verifies
>>>> whether we're creating a type with the same name of a predefined type
>>>> in Jolie (in which case we should not create the type) or not (in
>>>> which case we should create the type).
>>>>
>>>> What do you think?
>>>>
>>>> If this can work, the systematic way of doing it would be to have some
>>>> constant set or enum defined somewhere which contains the names of all
>>>> predefined types (I think we can reuse some predefined map from the
>>>> parser).
>>>>
>>>> - Fabrizio
>>>>
>>>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer
>>>> <mwa...@ya...> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> not really correct. It generates types like "type <name>:undefined",
>>>>> for
>>>>> instance in my case:
>>>>>>
>>>>>> type GetWeatherInformation:undefined
>>>>>
>>>>> So this is required in some cases.
>>>>>
>>>>> Cheers,
>>>>> Matthias
>>>>>
>>>>> Claudio Guidi schrieb:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> sorry for the delay.
>>>>>>
>>>>>> Do you mean this line?
>>>>>>
>>>>>> jolieTypes.add( createAnyOrUndefined( element.getName(), complexType )
>>>>>> );
>>>>>>
>>>>>> If I remember well it was commented because, otherwise, you will find
>>>>>>
>>>>>> type undefined: undefined
>>>>>>
>>>>>> into the generated interface.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------------------
>>>>>> Claudio Guidi Ph.D.
>>>>>> italianaSoftware s.r.l.
>>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>>>>>> http://www.italianasoftware.com/
>>>>>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>>>>>>
>>>>>> Phone: +39 0542 788201
>>>>>> Mobile: +39 347 0694065
>>>>>> Fax: +39 0542 628048
>>>>>> --------------------------------------------------------------
>>>>>>
>>>>>> Nota di riservatezza: Il presente messaggio, corredato dei relativi
>>>>>> allegati, contiene informazioni da considerarsi strettamente
>>>>>> riservate,
>>>>>> ed è
>>>>>> destinato esclusivamente al destinatario sopra indicato, il quale è
>>>>>> l'unico
>>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>>>>>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per
>>>>>> errore o
>>>>>> comunque lo leggesse senza esserne legittimato è avvertito che
>>>>>> trattenerlo,
>>>>>> copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è
>>>>>> severamente proibito, ed è pregato di rinviarlo immediatamente al
>>>>>> mittente
>>>>>> distruggendone l'originale.
>>>>>>
>>>>>> Grazie per la collaborazione.
>>>>>>
>>>>>>
>>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>>>>>> <mailto:fam...@gm...>>
>>>>>>
>>>>>>
>>>>>>       Hi all,
>>>>>>
>>>>>>       @Claudio: do you have any info on that line?
>>>>>>
>>>>>>       Cheers,
>>>>>>       Fabrizio.
>>>>>>
>>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer
>>>>>>       <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>>>>>>       > Any news on this one (and also on the Exception thing: Re:
>>>>>>       [Jolie-devel]
>>>>>>       > OneWay messages)?
>>>>>>       >
>>>>>>       > Matthias
>>>>>>       >
>>>>>>       > Fabrizio Montesi schrieb:
>>>>>>       >
>>>>>>       >> Hi all,
>>>>>>       >> I'm trying to see why that line has been commented...
>>>>>>       especially since
>>>>>>       >> it has been commented without leaving any other comment
>>>>>>       explaining the
>>>>>>       >> reason in the code. Claudio, any memories? :-)
>>>>>>       >>
>>>>>>       >> I see it's commented out in many parts of the code.
>>>>>>       >>
>>>>>>       >>
>>>>>>       >> Cheers,
>>>>>>       >> Fabrizio.
>>>>>>       >
>>>>>>       >
>>>>>>
>>>>>>
>

Re: [Jolie-devel] wsdl2jolie patches

[Matthias D. W. <mwa...@ya...>]

We should try to understand where and why the generation of
> type undefined:undefined
happened.

Just to make sure - I did not get it in my case (when un-commenting this 
particular codeline).

Matthias

Fabrizio Montesi schrieb:
> No, I mean that your type should be generated:
>
> type GetWeatherInformation:undefined
>
> whereas the following should not be generated:
>
> type undefined:undefined
>
>
> by implementing some check on the name of the type we are generating,
> to avoid redefining undefined. The latter is our main problem
> (@Claudio: right?).
>
>
>
> Ciao,
> Fabrizio.
>
> On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
>> Hi Fabrizio,
>>
>> did I get your point?
>>
>> You think that declarations as
>>> type GetWeatherInformation:undefined
>> should be omitted and all "GetWeatherInformation" appearances immediately be
>> substituted by "undefined"?
>>
>> Btw. in the WSDL file it is declared like this
>> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>>
>>> <s:element name="GetWeatherInformation"><s:complexType/></s:element>
>> So to be honest I do not see an issue to include it in Jolie's header as
>> well. The right thing would be to change the webservice to not include empty
>> complex types!
>>
>> Matthias
>>
>> Fabrizio Montesi schrieb:
>>
>>> Mmh... a possible solution could be that we add a check that verifies
>>> whether we're creating a type with the same name of a predefined type
>>> in Jolie (in which case we should not create the type) or not (in
>>> which case we should create the type).
>>>
>>> What do you think?
>>>
>>> If this can work, the systematic way of doing it would be to have some
>>> constant set or enum defined somewhere which contains the names of all
>>> predefined types (I think we can reuse some predefined map from the
>>> parser).
>>>
>>> - Fabrizio
>>>
>>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer
>>> <mwa...@ya...> wrote:
>>>> Hi all,
>>>>
>>>> not really correct. It generates types like "type <name>:undefined", for
>>>> instance in my case:
>>>>> type GetWeatherInformation:undefined
>>>> So this is required in some cases.
>>>>
>>>> Cheers,
>>>> Matthias
>>>>
>>>> Claudio Guidi schrieb:
>>>>> Hi all,
>>>>>
>>>>> sorry for the delay.
>>>>>
>>>>> Do you mean this line?
>>>>>
>>>>> jolieTypes.add( createAnyOrUndefined( element.getName(), complexType )
>>>>> );
>>>>>
>>>>> If I remember well it was commented because, otherwise, you will find
>>>>>
>>>>> type undefined: undefined
>>>>>
>>>>> into the generated interface.
>>>>>
>>>>>
>>>>>
>>>>> --------------------------------------------------------------
>>>>> Claudio Guidi Ph.D.
>>>>> italianaSoftware s.r.l.
>>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>>>>> http://www.italianasoftware.com/
>>>>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>>>>>
>>>>> Phone: +39 0542 788201
>>>>> Mobile: +39 347 0694065
>>>>> Fax: +39 0542 628048
>>>>> --------------------------------------------------------------
>>>>>
>>>>> Nota di riservatezza: Il presente messaggio, corredato dei relativi
>>>>> allegati, contiene informazioni da considerarsi strettamente riservate,
>>>>> ed è
>>>>> destinato esclusivamente al destinatario sopra indicato, il quale è
>>>>> l'unico
>>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>>>>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per
>>>>> errore o
>>>>> comunque lo leggesse senza esserne legittimato è avvertito che
>>>>> trattenerlo,
>>>>> copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è
>>>>> severamente proibito, ed è pregato di rinviarlo immediatamente al
>>>>> mittente
>>>>> distruggendone l'originale.
>>>>>
>>>>> Grazie per la collaborazione.
>>>>>
>>>>>
>>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>>>>> <mailto:fam...@gm...>>
>>>>>
>>>>>
>>>>>       Hi all,
>>>>>
>>>>>       @Claudio: do you have any info on that line?
>>>>>
>>>>>       Cheers,
>>>>>       Fabrizio.
>>>>>
>>>>>       On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer
>>>>>       <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>>>>>       > Any news on this one (and also on the Exception thing: Re:
>>>>>       [Jolie-devel]
>>>>>       > OneWay messages)?
>>>>>       >
>>>>>       > Matthias
>>>>>       >
>>>>>       > Fabrizio Montesi schrieb:
>>>>>       >
>>>>>       >> Hi all,
>>>>>       >> I'm trying to see why that line has been commented...
>>>>>       especially since
>>>>>       >> it has been commented without leaving any other comment
>>>>>       explaining the
>>>>>       >> reason in the code. Claudio, any memories? :-)
>>>>>       >>
>>>>>       >> I see it's commented out in many parts of the code.
>>>>>       >>
>>>>>       >>
>>>>>       >> Cheers,
>>>>>       >> Fabrizio.
>>>>>       >
>>>>>       >
>>>>>
>>>>>

Re: [Jolie-devel] wsdl2jolie patches

[Fabrizio M. <fam...@gm...>]

No, I mean that your type should be generated:

type GetWeatherInformation:undefined

whereas the following should not be generated:

type undefined:undefined


by implementing some check on the name of the type we are generating,
to avoid redefining undefined. The latter is our main problem
(@Claudio: right?).



Ciao,
Fabrizio.

On Tue, Dec 10, 2013 at 5:55 PM, Matthias Dieter Wallnöfer
<mwa...@ya...> wrote:
> Hi Fabrizio,
>
> did I get your point?
>
> You think that declarations as
>>
>> type GetWeatherInformation:undefined
>
> should be omitted and all "GetWeatherInformation" appearances immediately be
> substituted by "undefined"?
>
> Btw. in the WSDL file it is declared like this
> (http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
>
>> <s:element name="GetWeatherInformation"><s:complexType/></s:element>
>
> So to be honest I do not see an issue to include it in Jolie's header as
> well. The right thing would be to change the webservice to not include empty
> complex types!
>
> Matthias
>
> Fabrizio Montesi schrieb:
>
>> Mmh... a possible solution could be that we add a check that verifies
>> whether we're creating a type with the same name of a predefined type
>> in Jolie (in which case we should not create the type) or not (in
>> which case we should create the type).
>>
>> What do you think?
>>
>> If this can work, the systematic way of doing it would be to have some
>> constant set or enum defined somewhere which contains the names of all
>> predefined types (I think we can reuse some predefined map from the
>> parser).
>>
>> - Fabrizio
>>
>> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer
>> <mwa...@ya...> wrote:
>>>
>>> Hi all,
>>>
>>> not really correct. It generates types like "type <name>:undefined", for
>>> instance in my case:
>>>>
>>>> type GetWeatherInformation:undefined
>>>
>>> So this is required in some cases.
>>>
>>> Cheers,
>>> Matthias
>>>
>>> Claudio Guidi schrieb:
>>>>
>>>> Hi all,
>>>>
>>>> sorry for the delay.
>>>>
>>>> Do you mean this line?
>>>>
>>>> jolieTypes.add( createAnyOrUndefined( element.getName(), complexType )
>>>> );
>>>>
>>>> If I remember well it was commented because, otherwise, you will find
>>>>
>>>> type undefined: undefined
>>>>
>>>> into the generated interface.
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------
>>>> Claudio Guidi Ph.D.
>>>> italianaSoftware s.r.l.
>>>> via Coralli, 66 - 40026 Imola (BO), Italy
>>>> http://www.italianasoftware.com/
>>>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>>>>
>>>> Phone: +39 0542 788201
>>>> Mobile: +39 347 0694065
>>>> Fax: +39 0542 628048
>>>> --------------------------------------------------------------
>>>>
>>>> Nota di riservatezza: Il presente messaggio, corredato dei relativi
>>>> allegati, contiene informazioni da considerarsi strettamente riservate,
>>>> ed è
>>>> destinato esclusivamente al destinatario sopra indicato, il quale è
>>>> l'unico
>>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>>>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per
>>>> errore o
>>>> comunque lo leggesse senza esserne legittimato è avvertito che
>>>> trattenerlo,
>>>> copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è
>>>> severamente proibito, ed è pregato di rinviarlo immediatamente al
>>>> mittente
>>>> distruggendone l'originale.
>>>>
>>>> Grazie per la collaborazione.
>>>>
>>>>
>>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>>>> <mailto:fam...@gm...>>
>>>>
>>>>
>>>>      Hi all,
>>>>
>>>>      @Claudio: do you have any info on that line?
>>>>
>>>>      Cheers,
>>>>      Fabrizio.
>>>>
>>>>      On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer
>>>>      <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>>>>      > Any news on this one (and also on the Exception thing: Re:
>>>>      [Jolie-devel]
>>>>      > OneWay messages)?
>>>>      >
>>>>      > Matthias
>>>>      >
>>>>      > Fabrizio Montesi schrieb:
>>>>      >
>>>>      >> Hi all,
>>>>      >> I'm trying to see why that line has been commented...
>>>>      especially since
>>>>      >> it has been commented without leaving any other comment
>>>>      explaining the
>>>>      >> reason in the code. Claudio, any memories? :-)
>>>>      >>
>>>>      >> I see it's commented out in many parts of the code.
>>>>      >>
>>>>      >>
>>>>      >> Cheers,
>>>>      >> Fabrizio.
>>>>      >
>>>>      >
>>>>
>>>>
>

Re: [Jolie-devel] wsdl2jolie patches

[Matthias D. W. <mwa...@ya...>]

Hi Fabrizio,

did I get your point?

You think that declarations as
> type GetWeatherInformation:undefined
should be omitted and all "GetWeatherInformation" appearances 
immediately be substituted by "undefined"?

Btw. in the WSDL file it is declared like this 
(http://wsf.cdyne.com/WeatherWS/Weather.asmx?wsdl):
> <s:element name="GetWeatherInformation"><s:complexType/></s:element>
So to be honest I do not see an issue to include it in Jolie's header as 
well. The right thing would be to change the webservice to not include 
empty complex types!

Matthias

Fabrizio Montesi schrieb:
> Mmh... a possible solution could be that we add a check that verifies
> whether we're creating a type with the same name of a predefined type
> in Jolie (in which case we should not create the type) or not (in
> which case we should create the type).
>
> What do you think?
>
> If this can work, the systematic way of doing it would be to have some
> constant set or enum defined somewhere which contains the names of all
> predefined types (I think we can reuse some predefined map from the
> parser).
>
> - Fabrizio
>
> On Tue, Dec 10, 2013 at 5:11 PM, Matthias Dieter Wallnöfer
> <mwa...@ya...> wrote:
>> Hi all,
>>
>> not really correct. It generates types like "type <name>:undefined", for
>> instance in my case:
>>> type GetWeatherInformation:undefined
>> So this is required in some cases.
>>
>> Cheers,
>> Matthias
>>
>> Claudio Guidi schrieb:
>>> Hi all,
>>>
>>> sorry for the delay.
>>>
>>> Do you mean this line?
>>>
>>> jolieTypes.add( createAnyOrUndefined( element.getName(), complexType ) );
>>>
>>> If I remember well it was commented because, otherwise, you will find
>>>
>>> type undefined: undefined
>>>
>>> into the generated interface.
>>>
>>>
>>>
>>> --------------------------------------------------------------
>>> Claudio Guidi Ph.D.
>>> italianaSoftware s.r.l.
>>> via Coralli, 66 - 40026 Imola (BO), Italy
>>> http://www.italianasoftware.com/
>>> http://www.jolie-lang.org <http://www.jolie-lang.org/>
>>>
>>> Phone: +39 0542 788201
>>> Mobile: +39 347 0694065
>>> Fax: +39 0542 628048
>>> --------------------------------------------------------------
>>>
>>> Nota di riservatezza: Il presente messaggio, corredato dei relativi
>>> allegati, contiene informazioni da considerarsi strettamente riservate, ed è
>>> destinato esclusivamente al destinatario sopra indicato, il quale è l'unico
>>> autorizzato ad usarlo, copiarlo e, sotto la propria
>>> responsabilità,diffonderlo. Chiunque ricevesse questo messaggio per errore o
>>> comunque lo leggesse senza esserne legittimato è avvertito che trattenerlo,
>>> copiarlo,divulgarlo, distribuirlo a persone diverse dal destinatario è
>>> severamente proibito, ed è pregato di rinviarlo immediatamente al mittente
>>> distruggendone l'originale.
>>>
>>> Grazie per la collaborazione.
>>>
>>>
>>> 2013/12/9 Fabrizio Montesi <fam...@gm...
>>> <mailto:fam...@gm...>>
>>>
>>>
>>>      Hi all,
>>>
>>>      @Claudio: do you have any info on that line?
>>>
>>>      Cheers,
>>>      Fabrizio.
>>>
>>>      On Wed, Dec 4, 2013 at 5:50 PM, Matthias Dieter Wallnöfer
>>>      <mwa...@ya... <mailto:mwa...@ya...>> wrote:
>>>      > Any news on this one (and also on the Exception thing: Re:
>>>      [Jolie-devel]
>>>      > OneWay messages)?
>>>      >
>>>      > Matthias
>>>      >
>>>      > Fabrizio Montesi schrieb:
>>>      >
>>>      >> Hi all,
>>>      >> I'm trying to see why that line has been commented...
>>>      especially since
>>>      >> it has been commented without leaving any other comment
>>>      explaining the
>>>      >> reason in the code. Claudio, any memories? :-)
>>>      >>
>>>      >> I see it's commented out in many parts of the code.
>>>      >>
>>>      >>
>>>      >> Cheers,
>>>      >> Fabrizio.
>>>      >
>>>      >
>>>
>>>