fnorb-users — Mailing list for people who develop with Fnorb (replaces old fnorb@dstc.edu.au)

Re: [Fnorb-users] FNORB - Is anybody reading this?

[George F. <gfi...@ac...>]

>
>
>>I'm adding dynamic generation to Fnorb - is anybody interested in this?
>>    
>>
>
>Not sure what this means. If you are talking about some kind of
>automatic invocation of fnidl - I can't see why that could be
>useful.
>
>Regards,
>Martin
>  
>

This is a big selling point to ORBit2's python bindings - you just load 
the idl, and use the appropriate modules and classes.  If you're in a 
scripting language, you should be able to take advantage of this and 
eliminate the extra (explicit) generation step.

I'm not just building a one-time CORBA app, I'm working on a tool that 
allows users to plugin in their idl and make calls on it.  There's 
little to no value to having generated python on disk.

--George

Re: [Fnorb-users] FNORB - Is anybody reading this?

[<martin@v.loewis.de>]

George Finklang wrote:
> Does anybody read this list?  I got no responses from my last email.

I do.

> I'm adding dynamic generation to Fnorb - is anybody interested in this?

Not sure what this means. If you are talking about some kind of
automatic invocation of fnidl - I can't see why that could be
useful.

Regards,
Martin

[Fnorb-users] FNORB - Is anybody reading this?

[George F. <gfi...@ac...>]

Does anybody read this list?  I got no responses from my last email.

I'm adding dynamic generation to Fnorb - is anybody interested in this?

--George

[Fnorb-users] Intro and startup questions

[George F. <gfi...@ac...>]

Hi, I'm realtively new to CORBA and Fnorb, and I have a few questions.

1)  I notice that the mailing list only has a few subscribers.  What 
sort of projects are people using Fnorb for?  How active is development?

I'm exploring the possibility of using Fnorb internally to my app as a 
means of connecting with other ORBs, leading to the following question:

2)  I got the first connectivity test working with hello world and now 
I'm trying to get Fnorb to connect to some other ORBs.  Does anybody 
have this scenario working? 

For example, I've got weblogic 9.0 (eval) installed locally, and I'm 
trying to access an ejb deployed there through its IDL interface.  I'm 
trying to get connected to the name service at 
corbaloc:iiop:localhost:7001/NameService

but I can't seem to make a confirmed connection to the name service.

For example, I run:
orb = CORBA.ORB_init(['--ORBnaming-service=<corbaloc above>'])
and
orb.list_initial_services()
shows a name service registered, but
ns = orb.resolve_initial_references("NameService")
just gets me a
CORBA.Object instance, which I'm unable to narrow to
CosNaming.NamingContext with
ns._narrow(CosNaming.NameService) works, but
ns.list() for example gives me a TypeError, which leads me to believe 
that no actual connection has been made.

So, do people here have different ideas?  How to approach/diagnose this 
problem?  Experience connecting with other ORBs?

Thanks,

--George

[Fnorb-users] In SF area until the 7th of July

[Derek T. <der...@gm...>]

Hi all,

I'm actually in the San Francisco area until the 7th of July. If
anyone wants to talk to me about Fnorb, or just meet up, I'd be more
than happy to.

Regards,
Derek.

[Fnorb-users] polling reactor use

[Gerhard R. <gr...@ca...>]

Hi,

I need to integrate Fnorb mainloop with wxWindows. Do to so, I simply 
made the do_one_event method of SelectReactor available via the BOA 
interface. I intend to simply poll it from the idle callback of 
wxWindows. I attached the patch (which is for the latest CVS version) in 
case anyone is interested. I'm not sure how to _fnorb_quit makes sense 
in this case, there I did not try to support it at all :)

bye,
   Gerhard

Re: [Fnorb-users] interoperability ?

[<martin@v.loewis.de>]

Gerhard Reitmayr wrote:
> How well does Fnorb interoperate with other orbs for example OmniOrb ? 
> I'm interested in using Fnorb on Windows CE with python.

As long as the IDL compiles, Fnorb "should" interoperate just fine.
If it doesn't, it's a bug :-) Seriously, we do have open
interoperability bugs, but they are often easy to work out.

Regards,
Martin

[Fnorb-users] interoperability ?

[Gerhard R. <rei...@im...>]

Hi,

How well does Fnorb interoperate with other orbs for example OmniOrb ? 
I'm interested in using Fnorb on Windows CE with python.

thanks,
   Gerhard Reitmayr

[Fnorb-users] Fnorb status (with correct formatting!)

[Derek T. <de...@hi...>]

[Sorry about that last almost unreadable message, I am trying Mozilla 
Thunderbird, and did *not* expect it to screw around with my formatting 
after I hit "send". Why email clients do anything other than plaintext - 
without munging it - will forever be a mystery to me.]

Hi all,
 
After a long period during which I had very little time for Fnorb (yes, 
I changed jobs yet again) I have over the last few weekends been able to 
eek out time to work on it. If you look in Fnorb/orb/tests/POA, you'll 
see that I've started on some basic POA testing. I ought to be finished 
that by the end of today. In the process of getting this far with the 
tests I've actually managed to ferret out a bug in the client reactor 
that has always been there (or at least, since I started working on 
Fonrb), so it was well worth the effort just for that. It didn't handle 
the case where a read failed due to disconnection properly - it crashed 
the whole ORB. It was the nature of the test that I've constructed, 
where processes act as clients *and* servers, that uncovered that one. 
I've also brought the TkReactor class up to date.
 
Finally, I made a difficult decision regarding the use of servants as 
object references. Previously in Fnorb (i.e. with the BOA), you could 
pass a servant (or object implementation) as an argument where an object 
reference is required. This is pretty much impossible with a POA, 
because you can't know which specific POA the servant belongs to, if 
any. So after looking at the specs, and seeing that (I think) OmniORBpy 
doesn't allow this either, I've decided that, when using the POA, you 
have to pass proper object references. This isn't too onerous I hope, 
and it does have the benefit that you no longer have to pass an object 
adapter to servant constructors. So, having made that decision, I've 
adjusted all the code in the Fnorb repository to suit. If there are any 
issues with this decision, please, let's talk about it.
 
What does this leave, once I've done these POA tests, before the next 
release?
 
* Running the interoperability tests against other ORBs and fixing any 
issues.
* Finishing up the documentation (I've added the content IIRC, just 
needs an editorial pass)
* Bringing the language mapping as closely into line with the standard 
as we can now (should be very close already now we've got a POA, but a 
methodical check of any deficiences would be nice)
* Deciding what version(s) of Python we will support, and testing 
against those.
* Deciding if we will continue to support Jython, and testing against that.
 
If we get that done, it'll (finally) be release time. The next few weeks 
is a really, really, good time for me to try to plough through these and 
get the next release out there before work cranks up with another 
horrible cycle of evil deadlines, so if anyone can offer to take one of 
these tasks off my hands, I'd appreciate it!
 
Derek.

[Fnorb-users] Fnorb status

[Derek T. <de...@hi...>]

Hi all, 
 
After a long period during which I had very little time for Fnorb (yes, 
I changed jobs yet again) I have over the last few weekends been able to 
eek out time to work on it. If you look in Fnorb/tests/POA, you'll see 
that I've started on some basic POA testing. I ought to be finished that 
by the end of today. In the process of getting this far with the tests 
I've actually managed to ferret out a bug in the client reactor that has 
always been there (or at least, since I started working on Fonrb), so it 
was well worth the effort just for that. It didn't handle the case where 
a read failed due to disconnection properly - it crashed the whole ORB. 
It was the nature of the test that I've constructed, where processes act 
as clients *and* servers, that uncovered that one. I've also brought the 
TkReactor class up to date. 
 
Finally, I made a difficult decision regarding the use of servants as 
object references. Previously in Fnorb (i.e. with the BOA), you could 
pass a servant (or object implementation) as an argument where an object 
reference is required. This is pretty much impossible with a POA, 
because you can't know which specific POA the servant belongs to, if 
any. So after looking at the specs, and seeing that (I think) OmniORBpy 
doesn't allow this either, I've decided that, when using the POA, you 
have to pass proper object references. This isn't too onerous I hope, 
and it does have the benefit that you no longer have to pass an object 
adapter to servant constructors. So, having made that decision, I've 
adjusted all the code in the Fnorb repository to suit. If there are any 
issues with this decision, please, let's talk about it. 
 
What does this leave, once I've done these POA tests, before the next 
release? 
 
* Running the interoperability tests against other ORBs and fixing any 
issues. 
* Finishing up the documentation (I've added the content IIRC, just 
needs an editorial pass) 
* Bringing the language mapping as closely into line with the standard 
as we can now (should be very close already now we've got a POA, but a 
methodical check of any deficiences would be nice) 
* Deciding what version(s) of Python we will support, and testing 
against those. 
* Deciding if we will continue to support Jython, and testing against that. 
 
If we get that done, it'll (finally) be release time. The next few weeks 
is a really, really, good time for me to try to plough through these and 
get the next release out there before work cranks up with another 
horrible cycle of evil deadlines, so if anyone can offer to take one of 
these tasks off my hands, I'd appreciate it! 
 
Derek.

[Fnorb-users] Subscribe

[Gerard P. <Ger...@mo...>]

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <der...@gm...>]

On Wed, 10 Nov 2004 07:54:13 +0100, Martin v. L=F6wis <martin@v.loewis.de> =
wrote:
> Derek Thomson wrote:
> > And I was wondering what you thought of this potential problem in idl.g=
.
> > In that case, it was a bug and we've squashed it. Huzzah.
> >
> > Thanks for adding a test for LongLongs too. We will need to add one to
> > the interop tests too - do you have time or should I do that? I'm happy
> > to do it.
>=20
> I could add the test, but I couldn't readily run it - so please go
> ahead.

Sure. I understand perfectly. I have enough space *now* that I can
leave all the C++ ORBs we test against built on my machine. I had to
buy a hard drive just for that purpose :) It was frustrating having to
delete one just to build one of the others.

Regards,
Derek.

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <de...@hi...>]

Hi Tero,

Tero Saarni wrote:
> Derek Thomson wrote:
> 
>> Tero Saarni wrote:
>>
>>> ... and if I had looked a bit more carefully I would have noticed
>>> that idl.py is generated.  Here's a new try:
>>
>>
>> Yes, the way it was looks wrong to me! Well spotted! I think we might 
>> finally have it ... tell us how it goes when you try it against the 
>> Visibroker server!
> 
> 
> Yes that fixed my problem, it now works with the server!
> 

That is great news!

> 
>>> At this point OmniORB executes one extra method "_is_a()" which is
>>> not done by Fnorb.  I skip the dump of it since everything seems
>>> to go ok.
>>
>>
>> I guess that's possible. Is this OmniORB C++ or Python?
> 
> 
> It's Python, the script is basically the same for both ORBs excluding
> import statements of course.  Maybe _is_a() has something to do
> with this:
> 
>  http://omniorb.sourceforge.net/omnipy2/omniORBpy/omniORBpy003.html#htoc34
>  In cases 3 and 4, the ORB confirms the type of the object by calling
>  _is_a() just before the first invocation on the object.
> 
> In my case it was executed just before I made first call to Session object.

That's interesting. I don't think it's necessary though, so we'll leave 
Fnorb as is for the time being.

> 
> 
>>> Can you see something strange here?
>>
>>
>> Frankly, no, because the above code that you quoted doesn't contain 
>> any type information (unless you learn to read ASCIIfied typecodes 
>> directly ;) ). What did you mean there?
> 
> 
> I was just thinking if it would be possible to see the underlying primitive
> types inside the structure but that's probably not that straightforward...

Possible, yes, but painful to do by hand :)

> 
> Thanks for your help, this was a great learning experience!  And by the
> way, thanks to all of you for Fnorb.  It makes CORBA very attractive,
> being pure Python it's a snap to install and use.

Well, thank you for your patience and for actually finding the bug :) 
I've got very limited time to work on Fnorb, and so having users who 
actually understand that open source is a two way street and so get 
involved finding and fixing problems is a *huge* help!

I also like this idea of sending actual dumps of the GIOP messages like 
you did - I think I'll ask other people to do that in future. It's one 
of those ideas that's obvious in hindsight.

And yes, people do like the "immediacy" of Fnorb, I've noticed, even if 
(in theory) it shouldn't matter.

Regards,
Derek.

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Tero S. <ter...@ho...>]

Derek Thomson wrote:
>Tero Saarni wrote:
>
>>... and if I had looked a bit more carefully I would have noticed
>>that idl.py is generated.  Here's a new try:
>
>Yes, the way it was looks wrong to me! Well spotted! I think we might 
>finally have it ... tell us how it goes when you try it against the 
>Visibroker server!

Yes that fixed my problem, it now works with the server!


>>At this point OmniORB executes one extra method "_is_a()" which is
>>not done by Fnorb.  I skip the dump of it since everything seems
>>to go ok.
>
>I guess that's possible. Is this OmniORB C++ or Python?

It's Python, the script is basically the same for both ORBs excluding
import statements of course.  Maybe _is_a() has something to do
with this:

  http://omniorb.sourceforge.net/omnipy2/omniORBpy/omniORBpy003.html#htoc34
  In cases 3 and 4, the ORB confirms the type of the object by calling
  _is_a() just before the first invocation on the object.

In my case it was executed just before I made first call to Session object.


>>Can you see something strange here?
>
>Frankly, no, because the above code that you quoted doesn't contain any 
>type information (unless you learn to read ASCIIfied typecodes directly ;) 
>). What did you mean there?

I was just thinking if it would be possible to see the underlying primitive
types inside the structure but that's probably not that straightforward...
I then ended up trying a simpler interface which generated stubs that
were easier to understand for someone who don't know a heck about
ORBs :)


Thanks for your help, this was a great learning experience!  And by the
way, thanks to all of you for Fnorb.  It makes CORBA very attractive,
being pure Python it's a snap to install and use.

Best regards,
Tero

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <de...@hi...>]

Martin!

Martin v. L=F6wis wrote:
> Tero Saarni wrote:
>=20
>> ... and if I had looked a bit more carefully I would have noticed
>> that idl.py is generated.  Here's a new try:
>=20
>=20
> Thanks, committed as idl.g 1.12.
>=20

And I was wondering what you thought of this potential problem in idl.g.=20
In that case, it was a bug and we've squashed it. Huzzah.

Thanks for adding a test for LongLongs too. We will need to add one to=20
the interop tests too - do you have time or should I do that? I'm happy=20
to do it.

Regards,
Derek.

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <de...@hi...>]

Tero Saarni wrote:
> Tero Saarni wrote:
> 
>> I modified idl.py a little by looking an example on how "long long"
>> is converted.
> 
> 
> ... and if I had looked a bit more carefully I would have noticed
> that idl.py is generated.  Here's a new try:

Yes, the way it was looks wrong to me! Well spotted! I think we might 
finally have it ... tell us how it goes when you try it against the 
Visibroker server!

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <de...@hi...>]

Tero Saarni wrote:
> Derek Thomson wrote:
> 
>> Could you provide the dump of the GIOP request message from Fnorb like
>> you did before. That will at least tell me if the fix changed
>> anything!
> 
> 
> The message without arguments changed after the fix, but there
> seems to be another problem too that I've triggered...
> 
> See below for the packet dumps.

Okay, thanks for that.

> 
> Oh I see, alignment is done relative to start of the stream instead
> of start of each individual message.  Not exactly what I would
> guessed ;)
> 

Yes. It appears to be quite brittle this way i.e. one error early on can 
screw things up later even in completely different messages. But that's 
all part of the fun of binary protocols I suppose :)

> 
> I don't actually know yet since I haven't yet got familiar with the
> server end.  I'll get into that later if necessary.

Okay, I just ask as it would tell us if the incoming message was just 
being rejected by the server.

> 
> I'm in Finland (UTC + 2 hours) but I didn't succeed in writing this
> reply early enough...

Okay, cool. Now that I know what timezone you're in, I'll know when I 
can reasonably expect replies :)

> 
> 
> At this point OmniORB executes one extra method "_is_a()" which is
> not done by Fnorb.  I skip the dump of it since everything seems
> to go ok.

I guess that's possible. Is this OmniORB C++ or Python?

> 
> 
> My client doesn't actually use the transaction, it only needs the
> session object to pass around.  So I cancel the transaction by calling:
> 
> // no parameters and no return value
> session.rollback()
> 
> 
> Before the fix Fnorb added four bytes pad at the end.  It was now
> fixed by the newest version of GIOPClient.

Great! At least *that* won't be mucking things up.

> 
> The reply contains sequence of structs but the returned sequence
> contains only one element.
> 
> Reply seems to be interpreted incorrectly:
> 
> I previously mentioned that the unsigned long long value inside
> struct was 0x00564201.  That was printed out when testing with
> Fnorb.  The value sounded a bit strange and when looking into packet
> dumps it was stored as 4 bytes instead of 8.  Now I notices that
> when running the code with OmniORB the value is actually "1"!

Ah, so what I was interpreting as misaligned long long (8 bytes) was 
really padding + a too-short long long. Okay, that's possible, and given 
your later posts on the "unsigned long long" bug in fnidl I'd say it's 
even highly probable. I did wonder why the value was diffent between 
OmniORB and Fnorb, but thought the clients were just different somehow.

BTW when you're looking at the OmniORB dumps I've noticed that it looks 
like OmniORB reuses old buffers without clearing them. This is of course 
  allowed, but caused me confusion as it looked like the IOR part 
started far too early, when in fact this was just cruft in the padding 
bytes. That's why I first though there wasn't enough room for a long 
long, and wondered if your generated code was out of alignment with your 
IDL. But having realized that, I can actually make the OmniORB dumps 
make sense :)

Well, I'm glad it looks like the padding/alignment stuff is fixed (that 
would have been causing *some* problem, or at least would have 
eventually ;) ) but, yes, I agree with you that there's some problem 
with the IDL compiler WRT unsigned long longs.

> 
> Can you see something strange here?  

Frankly, no, because the above code that you quoted doesn't contain any 
type information (unless you learn to read ASCIIfied typecodes directly 
;) ). What did you mean there?

> Do you know what could be causing Fnorb to interpret the return
> value of get_MIBs() differenly?

Yes, a bug in the IDL compiler for unsigned long longs :)

It does fit the symptoms of the padding bug (i.e. an earlier message 
with no arguments, an 8-byte-aligned type that goes bad), so I was a 
little flustered when that update didn't fix it! I hope the IDL compiler 
fix sorts it out (finally) ...

Regards,
Derek.

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[<martin@v.loewis.de>]

Tero Saarni wrote:
> ... and if I had looked a bit more carefully I would have noticed
> that idl.py is generated.  Here's a new try:

Thanks, committed as idl.g 1.12.

Regards,
Martin

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Tero S. <ter...@ho...>]

Tero Saarni wrote:
>I modified idl.py a little by looking an example on how "long long"
>is converted.

... and if I had looked a bit more carefully I would have noticed
that idl.py is generated.  Here's a new try:


--- idl-orig.g	2004-11-08 21:35:53.874582268 +0200
+++ idl.g	2004-11-08 21:38:15.430799703 +0200
@@ -723,7 +723,7 @@
                             |
                             LONG long_long<<1>>
                             {{
-                                return self.p.unsigned_long_int()
+                                return long_long
                             }}
                         )


---
Tero

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Tero S. <ter...@ho...>]

Hi again,

It seems I cannot get "unsigned long long" to work even with
simplest possible example that just passes it in and out of methods.
It seems they get converted to plain "unsigned long" which I
tracked down to stubs themselves and Fnorb/parser/idl.py.

I modified idl.py a little by looking an example on how "long long"
is converted.  It seems to fix my simple example, but I haven't tried
if it also fixes my problems with VisiBroker.  I'll try that tomorrow.

Here's what I changed:

--- idl-orig.py	2004-11-08 20:55:19.854638296 +0200
+++ idl.py	2004-11-08 21:00:24.398464593 +0200
@@ -765,7 +765,9 @@
                 return self.p.unsigned_short_int()
             elif _token_ == 'LONG':
                 LONG = self._scan('LONG')
-                long_long = self.long_long(1)
+                if _token_ in ['LONG', 'IDENTIFIER', 'RPAREN', "'>'", 
"','", "';'"]:
+                    long_long = self.long_long(1)
+                    return long_long
                 return self.p.unsigned_long_int()
             else:
                 raise SyntaxError(self._pos, 'Could not match 
integer_type')


Actually I have no idea why IDENTIFIER, RPAREN etc are grouped to
the same action as I'm not very familiar with IDL syntax.  I just copied
the "if" from the above rule for "long long".

Best regards,
Tero

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Tero S. <ter...@ho...>]

Derek Thomson wrote:
>Could you provide the dump of the GIOP request message from Fnorb like
>you did before. That will at least tell me if the fix changed
>anything!

The message without arguments changed after the fix, but there
seems to be another problem too that I've triggered...

See below for the packet dumps.


>no arguments that starts that mis-alignment problem. It could be one
>of the others in theory, but that's the most likely. Anyway that data
>would tell me if Fnorb really is getting that bit wrong.

Oh I see, alignment is done relative to start of the stream instead
of start of each individual message.  Not exactly what I would
guessed ;)


>Secondly, on the operation that returns "NO_RESOURCE", does the method
>actually get executed on the server?

I don't actually know yet since I haven't yet got familiar with the
server end.  I'll get into that later if necessary.


>right now, but I think we're close. To save us some time (I'm not sure 
>where you are but it's probably not Australia) could you try some things 
>and tell me what happens so that we can narrow it down? I'll then be able 
>to look at the results when I get home tonight my time.

I'm in Finland (UTC + 2 hours) but I didn't succeed in writing this
reply early enough...


Ok, here we go:
-----------------------


// config is object reference
// session is object reference
// foo is string, 120 is long
session = config.create_session('foo', 120)

Fnorb request
0030                    47 49  4f 50 01 02 00 00 00 00   `.S...GI OP......
0040  00 70 00 00 00 01 03 00  00 00 00 00 00 00 00 00   .p...... ........
0050  00 39 00 50 4d 43 00 00  00 04 00 00 00 10 2f 70   .9.PMC.. ....../p
0060  65 72 73 69 73 74 65 6e  74 5f 70 6f 61 00 00 00   ersisten t_poa...
0070  00 19 43 65 6c 6c 6f 43  6f 6e 66 69 67 75 72 61   ..CelloC onfigura
0080  74 69 6f 6e 53 65 72 76  69 63 65 00 00 00 00 00   tionServ ice.....
0090  00 0f 63 72 65 61 74 65  5f 73 65 73 73 69 6f 6e   ..create _session
00a0  00 00 00 00 00 00 00 00  00 04 66 6f 6f 00 00 00   ........ ..foo...
00b0  00 78

OmniORB request
0030                    47 49  4f 50 01 02 00 00 00 00   `.....GI OP......
0040  00 70 00 00 00 04 03 00  00 00 00 00 00 39 00 00   .p...... .....9..
0050  00 39 00 50 4d 43 00 00  00 04 00 00 00 10 2f 70   .9.PMC.. ....../p
0060  65 72 73 69 73 74 65 6e  74 5f 70 6f 61 00 00 00   ersisten t_poa...
0070  00 19 43 65 6c 6c 6f 43  6f 6e 66 69 67 75 72 61   ..CelloC onfigura
0080  74 69 6f 6e 53 65 72 76  69 63 65 73 0c 00 00 00   tionServ ices....
0090  00 0f 63 72 65 61 74 65  5f 73 65 73 73 69 6f 6e   ..create _session
00a0  00 5f 00 00 00 00 00 00  00 04 66 6f 6f 00 00 00   ._...... ..foo...
00b0  00 78                                              .x

Reply is the same for both:
0030                    47 49  4f 50 01 02 00 01 00 00    .....GI OP......
0040  00 74 00 00 00 04 00 00  00 00 00 00 00 00 00 00   .t...... ........
0050  00 1c 49 44 4c 3a 42 61  73 69 63 43 6f 6e 66 69   ..IDL:Ba sicConfi
0060  67 2f 53 65 73 73 69 6f  6e 3a 31 2e 30 00 00 00   g/Sessio n:1.0...
0070  00 01 00 00 00 00 00 00  00 3c 00 01 02 00 00 00   ........ .<......
0080  00 0b 31 30 2e 31 30 2e  30 2e 32 32 00 00 de 02   ..10.10. 0.22....
0090  00 00 00 00 00 1c 00 56  42 01 00 00 00 02 2f 00   .......V B...../.
00a0  20 20 00 00 00 04 00 00  00 03 00 00 00 00 00 00     ...... ........
00b0  2c 1c 00 00 00 00


At this point OmniORB executes one extra method "_is_a()" which is
not done by Fnorb.  I skip the dump of it since everything seems
to go ok.


My client doesn't actually use the transaction, it only needs the
session object to pass around.  So I cancel the transaction by calling:

// no parameters and no return value
session.rollback()

Fnorb
0030                    47 49  4f 50 01 02 00 00 00 00   `.f...GI OP......
0040  00 40 00 00 00 02 03 00  00 00 00 00 00 00 00 00   .@...... ........
0050  00 1c 00 56 42 01 00 00  00 02 2f 00 20 20 00 00   ...VB... ../.  ..
0060  00 04 00 00 00 02 00 00  00 00 00 00 2c 1c 00 00   ........ ....,...
0070  00 09 72 6f 6c 6c 62 61  63 6b 00 00 00 00 00 00   ..rollba ck......
0080  00 00

Before the fix Fnorb added four bytes pad at the end.  It was now
fixed by the newest version of GIOPClient.

OmniORB
0030                    47 49  4f 50 01 02 00 00 00 00   `.....GI OP......
0040  00 40 00 00 00 08 03 00  00 00 00 00 00 39 00 00   .@...... .....9..
0050  00 1c 00 56 42 01 00 00  00 02 2f 00 20 20 00 00   ...VB... ../.  ..
0060  00 04 00 00 00 03 00 00  00 00 00 00 2c 1c 00 00   ........ ....,...
0070  00 09 72 6f 6c 6c 62 61  63 6b 00 00 00 00 00 00   ..rollba ck......
0080  00 00

Reply from Visibroker to Fnorb
0030                    47 49  4f 50 01 02 00 01 00 00    ..H..GI OP......
0040  00 0c 00 00 00 02 00 00  00 00 00 00 00 00         ........ ......

Reply from VisiBroker to OmniORB
0030  20 00 7f c7 00 00 47 49  4f 50 01 02 00 01 00 00    .....GI OP......
0040  00 0c 00 00 00 08 00 00  00 00 00 00 00 00         ........ ......


The next method call:

// miblist is sequence of structs. Struct contains unsigned long long
// session is object reference
miblist = config.get_MIBs(session)

Fnorb
0030                    47 49  4f 50 01 02 00 00 00 00   `.%...GI OP......
0040  00 cc 00 00 00 03 03 00  00 00 00 00 00 00 00 00   ........ ........
0050  00 39 00 50 4d 43 00 00  00 04 00 00 00 10 2f 70   .9.PMC.. ....../p
0060  65 72 73 69 73 74 65 6e  74 5f 70 6f 61 00 00 00   ersisten t_poa...
0070  00 19 43 65 6c 6c 6f 43  6f 6e 66 69 67 75 72 61   ..CelloC onfigura
0080  74 69 6f 6e 53 65 72 76  69 63 65 00 00 00 00 00   tionServ ice.....
0090  00 09 67 65 74 5f 4d 49  42 73 00 00 00 00 00 00   ..get_MI Bs......
00a0  00 00 00 00 00 00 00 00  00 1c 49 44 4c 3a 42 61   ........ ..IDL:Ba
00b0  73 69 63 43 6f 6e 66 69  67 2f 53 65 73 73 69 6f   sicConfi g/Sessio
00c0  6e 3a 31 2e 30 00 00 00  00 01 00 00 00 00 00 00   n:1.0... ........
00d0  00 3c 00 01 02 00 00 00  00 0b 31 30 2e 31 30 2e   .<...... ..10.10.
00e0  30 2e 32 32 00 00 de 02  00 00 00 00 00 1c 00 56   0.22.... .......V
00f0  42 01 00 00 00 02 2f 00  20 20 00 00 00 04 00 00   B...../.   ......
0100  00 02 00 00 00 00 00 00  2c 1c 00 00 00 00         ........ ,.....

OmniORB
0030                    47 49  4f 50 01 02 00 00 00 00   `..n..GI OP......
0040  00 cc 00 00 00 0a 03 00  00 00 00 00 00 39 00 00   ........ .....9..
0050  00 39 00 50 4d 43 00 00  00 04 00 00 00 10 2f 70   .9.PMC.. ....../p
0060  65 72 73 69 73 74 65 6e  74 5f 70 6f 61 00 00 00   ersisten t_poa...
0070  00 19 43 65 6c 6c 6f 43  6f 6e 66 69 67 75 72 61   ..CelloC onfigura
0080  74 69 6f 6e 53 65 72 76  69 63 65 43 6f 6e 00 00   tionServ iceCon..
0090  00 09 67 65 74 5f 4d 49  42 73 00 2e 30 00 00 00   ..get_MI Bs..0...
00a0  00 00 00 00 00 00 00 00  00 1c 49 44 4c 3a 42 61   ........ ..IDL:Ba
00b0  73 69 63 43 6f 6e 66 69  67 2f 53 65 73 73 69 6f   sicConfi g/Sessio
00c0  6e 3a 31 2e 30 00 00 00  00 01 00 00 00 00 00 00   n:1.0... ........
00d0  00 3c 00 01 02 00 00 00  00 0b 31 30 2e 31 30 2e   .<...... ..10.10.
00e0  30 2e 32 32 00 00 de 02  00 00 00 00 00 1c 00 56   0.22.... .......V
00f0  42 01 00 00 00 02 2f 00  20 20 00 00 00 04 00 00   B...../.   ......
0100  00 03 00 00 00 00 00 00  2c 1c 00 00 00 00         ........ ,.....


The reply contains sequence of structs but the returned sequence
contains only one element.

Reply seems to be interpreted incorrectly:

I previously mentioned that the unsigned long long value inside
struct was 0x00564201.  That was printed out when testing with
Fnorb.  The value sounded a bit strange and when looking into packet
dumps it was stored as 4 bytes instead of 8.  Now I notices that
when running the code with OmniORB the value is actually "1"!

Reply to Fnorb
0030                    47 49  4f 50 01 02 00 01 00 00    .....GI OP......
0040  00 1c 00 00 00 03 00 00  00 00 00 00 00 00 00 00   ........ ........
0050  00 01 00 56 42 01 00 00  00 00 00 00 00 01         ...VB... ......

Reply to OmniORB
0030                    47 49  4f 50 01 02 00 01 00 00    .<\..GI OP......
0040  00 1c 00 00 00 0a 00 00  00 00 00 00 00 00 00 00   ........ ........
0050  00 01 00 56 42 01 00 00  00 00 00 00 00 01         ...VB... ......

Seems that Fnorb reads the value at wrong place...  I paste some parts
of the stub here.  Method get_MIBs() contains:

# Typecodes for 'in' and 'inout' parameters.
inputs = []
inputs.append(Fnorb.orb.CORBA.TC_Object)

# Typecodes for the result, 'inout' and 'out' parameters.
outputs = []
outputs.append(Fnorb.orb.CORBA.typecode("IDL:BasicConfig/MIBRefSeq:1.0"))


Type definition for MIBRefSeq:

# Alias: IDL:BasicConfig/MIBRefSeq:1.0
Fnorb.orb.TypeManager.TypeManager_init().add_type("IDL:BasicConfig/MIBRefSeq:1.0
", 
"000000000000001300000088000000000000000F00000078000000000000001B49444C3A4261
736963436F6E6669672F4D49425265663A312E300000000000074D49425265660000000000010000
00046F6964000000001500000034000000000000001C49444C3A4261736963436F6E6669672F4F49
44545950453A312E3000000000084F494454595045000000000500000000", None)

Type definition for MIBRef:

class MIBRef:
    """ Struct: IDL:BasicConfig/MIBRef:1.0 """

    _FNORB_ID = "IDL:BasicConfig/MIBRef:1.0"

    def __init__(self, _oid):
        """ Constructor. """

        self.oid = _oid
        return

    def __getinitargs__(self):
        """ Return the constructor arguments for unpickling. """

        return (self.oid,)

Fnorb.orb.TypeManager.TypeManager_init().add_type("IDL:BasicConfig/MIBRef:1.0",
"000000000000000F00000078000000000000001B49444C3A4261736963436F6E6669672F4D49425
265663A312E300000000000074D4942526566000000000001000000046F696400000000150000003
4000000000000001C49444C3A4261736963436F6E6669672F4F4944545950453A312E30000000000
84F4944545950450000000005", MIBRef)


Can you see something strange here?  The original IDL is

  struct MIBRef {
    OIDTYPE oid;
  };
  typedef sequence<MIBRef> MIBRefSeq;



Then finally in my script I call the method that still fails with
NO_RESOURCES:

// mib is the first struct from miblist returned by previous method
// session is ref to object without attributes
// the method returns object reference
config.basic_get_root_MO(mib, session)


Here the parameters start at offset 0xae and starts with the
wrongly parsed 4 byte value 0x00564201:

Fnorb
0030                    47 49  4f 50 01 02 00 00 00 00   `.....GI OP......
0040  00 d8 00 00 00 04 03 00  00 00 00 00 00 00 00 00   ........ ........
0050  00 39 00 50 4d 43 00 00  00 04 00 00 00 10 2f 70   .9.PMC.. ....../p
0060  65 72 73 69 73 74 65 6e  74 5f 70 6f 61 00 00 00   ersisten t_poa...
0070  00 19 43 65 6c 6c 6f 43  6f 6e 66 69 67 75 72 61   ..CelloC onfigura
0080  74 69 6f 6e 53 65 72 76  69 63 65 00 00 00 00 00   tionServ ice.....
0090  00 12 62 61 73 69 63 5f  67 65 74 5f 72 6f 6f 74   ..basic_ get_root
00a0  5f 4d 4f 00 00 00 00 00  00 00 00 00 00 00 00 56   _MO..... .......V
00b0  42 01 00 00 00 1c 49 44  4c 3a 42 61 73 69 63 43   B.....ID L:BasicC
00c0  6f 6e 66 69 67 2f 53 65  73 73 69 6f 6e 3a 31 2e   onfig/Se ssion:1.
00d0  30 00 00 00 00 01 00 00  00 00 00 00 00 3c 00 01   0....... .....<..
00e0  02 00 00 00 00 0b 31 30  2e 31 30 2e 30 2e 32 32   ......10 .10.0.22
00f0  00 00 de 02 00 00 00 00  00 1c 00 56 42 01 00 00   ........ ...VB...
0100  00 02 2f 00 20 20 00 00  00 04 00 00 00 02 00 00   ../.  .. ........
0110  00 00 00 00 2c 1c 00 00  00 00                     ....,... ..

OmniORB
0030                    47 49  4f 50 01 02 00 00 00 00   `.WS..GI OP......
0040  00 dc 00 00 00 0c 03 00  00 00 00 00 00 39 00 00   ........ .....9..
0050  00 39 00 50 4d 43 00 00  00 04 00 00 00 10 2f 70   .9.PMC.. ....../p
0060  65 72 73 69 73 74 65 6e  74 5f 70 6f 61 00 00 00   ersisten t_poa...
0070  00 19 43 65 6c 6c 6f 43  6f 6e 66 69 67 75 72 61   ..CelloC onfigura
0080  74 69 6f 6e 53 65 72 76  69 63 65 43 6f 6e 00 00   tionServ iceCon..
0090  00 12 62 61 73 69 63 5f  67 65 74 5f 72 6f 6f 74   ..basic_ get_root
00a0  5f 4d 4f 00 00 00 00 00  00 00 49 44 4c 3a 00 00   _MO..... ..IDL:..
00b0  00 00 00 00 00 01 00 00  00 1c 49 44 4c 3a 42 61   ........ ..IDL:Ba
00c0  73 69 63 43 6f 6e 66 69  67 2f 53 65 73 73 69 6f   sicConfi g/Sessio
00d0  6e 3a 31 2e 30 00 00 00  00 01 00 00 00 00 00 00   n:1.0... ........
00e0  00 3c 00 01 02 00 00 00  00 0b 31 30 2e 31 30 2e   .<...... ..10.10.
00f0  30 2e 32 32 00 00 de 02  00 00 00 00 00 1c 00 56   0.22.... .......V
0100  42 01 00 00 00 02 2f 00  20 20 00 00 00 04 00 00   B...../.   ......
0110  00 03 00 00 00 00 00 00  2c 1c 00 00 00 00         ........ ,.....

OmniORB packet contains the 8 byte 0x0000000000000001.
That explains the different length of above messages.

Do you know what could be causing Fnorb to interpret the return
value of get_MIBs() differenly?

Best regards,
Tero

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <der...@gm...>]

Hi Tero,

I've got a minute before lunch :) and I thought of a couple of other
things you could help me with.

Could you provide the dump of the GIOP request message from Fnorb like
you did before. That will at least tell me if the fix changed
anything! Even better, the dump from *all* the request messages you
listed earlier would be useful, as it's (probably) the operation with
no arguments that starts that mis-alignment problem. It could be one
of the others in theory, but that's the most likely. Anyway that data
would tell me if Fnorb really is getting that bit wrong.

Secondly, on the operation that returns "NO_RESOURCE", does the method
actually get executed on the server?

Thanks,
Derek.

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <de...@hi...>]

Tero Saarni wrote:

> Hi Derek,
>
> Thanks for the fix, I downloaded the lates version of the source code
> from CVS together with the new versions of GIOPClient.py and
> GIOPServer.py.  Unfortunately that didn't seem to be the problem in
> my case :-(



That's a shame, because I'm quite certain that this is the problem. I 
have to go to work now, and so I can't give you a full explanation right 
now, but I think we're close. To save us some time (I'm not sure where 
you are but it's probably not Australia) could you try some things and 
tell me what happens so that we can narrow it down? I'll then be able to 
look at the results when I get home tonight my time.

This problem is related to the padding when a request has no "body", so 
firstly can you try adding a dummy argument to the operation that 
currently has no arguments (I think it was "create_session"?), alter the 
client and server to suit, and see what happens?

Secondly, this manifests when 8-byte alignment is required, so can you 
put everything back again from the above test (ie. make it fail again), 
then change "unsigned long long" to just "unsigned long", rebuild and 
see what happens?

Finally, can we see the IDL signature for the operation with no 
arguments ("create_session")? I'm thinking maybe there's something 
interesting there, and the code for testing if we need the 8-byte 
aligned padding is missing it.

Anyway, I'll get back to you with a more detailed explanation of why I 
think this *is* the problem tonight (my time). I've got to run right now ...

Regards,
Derek.

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Tero S. <ter...@ho...>]

Hi Derek,

Thanks for the fix, I downloaded the lates version of the source code
from CVS together with the new versions of GIOPClient.py and
GIOPServer.py.  Unfortunately that didn't seem to be the problem in
my case :-(

Derek Thomson wrote:
>Okay, that helps. Can you tell me what a "Session" is as well? I'm just 
>trying to pick apart that fragment of the message ...

Session is an object / interface without any attributes.


> > Here OIDTYPE is typedeffed as unsigned long long.
>
>Looking at the dump for OmniORB, I noticed something interesting. There 
>just isn't room for an "unsigned long long" between the end of the request 
>header and the start of the "session" arguments. In fact, it's just not 
>there.

I now printed out the value of the only attribute in mib structure
and it seems to be 0x00564201 every time I run the client script.


>So, I have to ask the obvious question - is all your generated client and 
>skeleton code lined up for Visibroker, Fnorb and OmniORB? That is, all 
>generated from the same version of the IDL? It looks to me like OmniOrb 
>doesn't know about the MIBRef argument at all, and that only the Fnorb 
>fnidl-generated client stub is inserting the "unsigned long long" (ie. 
>MIBRef). What do you think?
...
>Yes, I've gone through the headers and that part looks fine, it just goes 
>pear shaped at the start of the marshalling of the arguments. As you can 
>see, Fnorb is writing out enough bytes to cater for the unsigned long long, 
>and OmniORB isn't, which makes me wonder if this isn't simply a case of 
>mis-aligned generated code.

I'm not familiar with how the parameters are written out into GIOP
packets but in this case Fnorb generated header that was 4 bytes
shorter than OmniORB header.  Still it seems thet store the MIBRef
value 0x00564201 exactly the same way so I suppose it must be ok,
although I thought "unsigned long long" would take 8 bytes instead
of 4?

I've generated the Fnorb and OmniORB stubs myself and I used the
same IDL file except for small fixes that OmniORB required:  it insisted
on case insensitive names, IDL compiler didn't accept method signatures
like "method(in Session session)" where type name and forman
parameter name collide.

The server end is pre-compiled but I'm pretty sure the IDL hasn't
changed at least on these parts of the interface (backed up
by the fact that client script works with OmniORB).

Fnidl generated code for the failing method is here:

    def basic_get_root_MO(self, *args, **kw):
        """ Operation: 
IDL:BasicConfig/BasicConfiguration/basic_get_root_MO:1.0 """

        # Typecodes for 'in' and 'inout' parameters.
        inputs = []
        
inputs.append(Fnorb.orb.CORBA.typecode("IDL:BasicConfig/MIBRef:1.0"))
        inputs.append(Fnorb.orb.CORBA.TC_Object)

        # Typecodes for the result, 'inout' and 'out' parameters.
        outputs = []
        
outputs.append(Fnorb.orb.CORBA.typecode("IDL:BasicConfig/MORef:1.0"))

        # Typecodes for user exceptions.
        exceptions = []
        
exceptions.append(Fnorb.orb.CORBA.typecode("IDL:BasicConfig/ProcessingFailure:1.0"))
        
exceptions.append(Fnorb.orb.CORBA.typecode("IDL:BasicConfig/SecurityViolation:1.0"))
        
exceptions.append(Fnorb.orb.CORBA.typecode("IDL:BasicConfig/NotDefined:1.0"))

        # Create a request object.
        request = self._create_request("basic_get_root_MO", inputs, outputs, 
exceptions)

        # Make the request!
        apply(request.invoke, args, kw)

        # Return the results.
        return request.results()


Best regards,
Tero

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.com/

Re: [Fnorb-users] Fnorb, VisiBroker and CORBA.NO_RESOURCES

[Derek T. <de...@hi...>]

Hi Tero,

Tero Saarni wrote:
> Derek Thomson wrote:
> 
>> Okay, I see from the dump that it's GIOP 1.2. There's an outstanding 
>> bug related to GIOP 1.2 that I'm patching up now. 
> 
> That sounds promising. 

Okay, I've finally checked in the fix for the alignment bug. I've tested 
it against OmniORB, and it seems to work fine.

This slipped through because our interoperability tests didn't have any 
operations with no arguments which (annoyingly) only started to matter 
for GIOP 1.2 ... I've got a test now that I want to re-organize before I 
check it in, but it will be added.

Anyway, try that and see what happens. The altered files are 
GIOPClient.py and GIOPServer.py.

Regards,
Derek.