[omniORB] omniORBpy equivalent of setLogFunction ?
Daniel Greenblatt
dan at cgl.ucsf.edu
Mon Nov 17 16:12:06 GMT 2003
Is there any way, using omniORBpy 2.1 to redirect ORB trace output to a
file ?
I know omniORB has the setLogFunction method, but the only thing that
strikes me as interesting in the omniORB module is the 'log' function..
Can anyone suggest a workaround ?
Thanks,
Dan
----------------------------
Daniel Greenblatt
UCSF Computer Graphics Lab
dan at cgl.ucsf.edu
On Mon, 17 Nov 2003 omniorb-list-request at omniorb-support.com wrote:
> Date: Mon, 17 Nov 2003 18:52:56 +0000
> From: omniorb-list-request at omniorb-support.com
> Reply-To: omniorb-list at omniorb-support.com
> To: omniorb-list at omniorb-support.com
> Subject: omniORB-list Digest, Vol 7, Issue 20
>
> Send omniORB-list mailing list submissions to
> omniorb-list at omniorb-support.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> or, via email, send a message with subject or body 'help' to
> omniorb-list-request at omniorb-support.com
>
> You can reach the person managing the list at
> omniorb-list-owner at omniorb-support.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of omniORB-list digest..."
>
>
> Today's Topics:
>
> 1. Re: Two Servers, One Client (Duncan Grisby)
> 2. Re: invalid warning while destroying compound DynAnys
> (Duncan Grisby)
> 3. omniORB for mac os x carbon (Thomas Byrdal)
> 4. Re: omniName GUI (baileyk at schneider.com)
> 5. Re: request for dropping site-packages/PortableServer* from
> omniorbpy (Thomas Lockhart)
> 6. Re: invalid warning while destroying compound DynAnys
> (Renzo Tomaselli)
> 7. Re: AIX: pure virtual method called (Renzo Tomaselli)
> 8. RE: omniName GUI (JHJE (Jan Holst Jensen))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Nov 2003 12:00:30 +0000
> From: Duncan Grisby <duncan at grisby.org>
> Subject: Re: [omniORB] Two Servers, One Client
> To: Johan Cronje <jcronje at dsp.sun.ac.za>
> Cc: omniorb-list at omniorb-support.com
> Message-ID: <200311171200.hAHC0Ur32264 at grisby.dyndns.org>
>
> On Monday 17 November, Johan Cronje wrote:
>
> > > This is a mistake. You should only be running one naming service. You
> > > should therefore only give a reference to one of them in the InitRef
> > > configuration.
> >
> > Does this mean that must I have only ONE daemon running on ONE machine and
> > then instruct ALL clients from ALL machines to use that ONE naming service
> > daemon? Sorry if this is trivial, but I only now realised that this is how it
> > is likely to be supposed to be done.
>
> Yes. Precisely. That's the way all the machines get to share the same
> name to object mappings.
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- duncan at grisby.org --
> -- http://www.grisby.org --
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 17 Nov 2003 12:49:03 +0000
> From: Duncan Grisby <duncan at grisby.org>
> Subject: Re: [omniORB] invalid warning while destroying compound
> DynAnys
> To: "Renzo Tomaselli" <renzo.tomaselli at tecnotp.it>
> Cc: Omniorb list <omniorb-list at omniorb-support.com>
> Message-ID: <200311171249.hAHCn3h32489 at grisby.dyndns.org>
>
> On Friday 14 November, "Renzo Tomaselli" wrote:
>
> > while destroying compound DynAnys, we get a warning (if trace level is
> > 25) from dynAny.cc, line#323.
> > This warning occurs at each nested component since it appears to have
> > pd_is_root == 1, while (I guess) this should be true only for the top level
> > DynAny (e.g. the container).
>
> Yes, pd_is_root should only be true for the top level DynAny. Can you
> provide some (minimal) example code that exhibits the problem?
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby --
> -- duncan at grisby.org --
> -- http://www.grisby.org --
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 17 Nov 2003 13:55:41 +0100
> From: "Thomas Byrdal" <tbc at northmann.com>
> Subject: [omniORB] omniORB for mac os x carbon
> To: <omniorb-list at omniorb-support.com>
> Message-ID: <00ec01c3ad0a$1b8a6a00$4d01a8c0 at nougat>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
>
> I am in a desperate need of omniORB for Mac OS X as a shared carbon library.
> I have downloaded the 4.0.2 version of omniORN and build the CodeWorrier
> project supplied by Wolfgang Textor. Unfortunately it does not work on
> Mac OS X, since GUSI does not work on Mac OS X.
> I have tried building omniORB with a special version of GUSI, used by the
> MacPython project, that should be carbonized. Unfortunately this doesn't
> work either.
>
> Does anybody know how to build a omniORB for Mac OS X as a shared carbon
> library ?
>
> Any help or suggestions will be greatly apreciated.
>
> Thanks in advance,
> Thomas Byrdal
> tbc at northmann dot com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20031117/6c9367a1/attachment-0001.htm
>
> ------------------------------
>
> Message: 4
> Date: Mon, 17 Nov 2003 09:05:40 -0600
> From: baileyk at schneider.com
> Subject: Re: [omniORB] omniName GUI
> To: <omniorb-list at omniorb-support.com>, FredP
> <frederic.prin at silvaco.com>
> Message-ID: <OF7CE8CD4B.79230920-ON86256DE1.00518EDE at schneider.com>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Here's one that I've done just as a project to learn Python qt bindings.
> It uses omniORBpy and PyQt. It's not packaged nicely or anything, but if
> you get the necessary env vars set (PATH, QTDIR, PYTHONPATH, OMNIORB_CFG)
> you can run the pyntb/ntb script to start it. Or just run the
> pyntb/pyntb/main.py file. I planned to have it do lots of fancy stuff, but
> haven't touched it for a while. It has four panes
> 1. Upper left : the name tree
> 2. Upper right : information
> 3. Bottom : Python interpreter interactive input
> 4. Middle right : interpreter output
>
> You can right-click on contexts and object nodes and get a few actions
> (like invoking _non_existent() or using catior to see the endpoint
> details).
>
> Feel free to do whatever you like with it. If I added a way to destroy
> sub-trees and add bindings I'd use it more. As it is I use a hacked
> version of the WebSphere JNTB (Java Name Tree Browser).
>
> Kendall
>
> PyNTB has been tested only on Solaris 8 with QT3 and omniORBpy 2.0.
>
> (See attached file: pyntb.tgz)
>
>
>
>
> "FredP"
> <frederic.prin at silvaco.com> To: <omniorb-list at omniorb-support.com>
> Sent by: cc:
> omniorb-list-bounces at omniorb- Fax to:
> support.com Subject: [omniORB] omniName GUI
>
>
> 11/17/2003 04:35 AM
> Please respond to FredP
>
>
>
>
>
>
> Hi all,
>
> Is there someone who knows a graphical tool that can display the internal
> table of omniNames bindings graph ?
>
> TIA
>
> FredP_______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: pyntb.tgz
> Type: application/octet-stream
> Size: 4025 bytes
> Desc: not available
> Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20031117/e2e382be/pyntb-0001.obj
>
> ------------------------------
>
> Message: 5
> Date: Mon, 17 Nov 2003 08:54:45 -0800
> From: Thomas Lockhart <lockhart at fourpalms.org>
> Subject: Re: [omniORB] request for dropping
> site-packages/PortableServer* from omniorbpy
> To: Duncan Grisby <duncan at grisby.org>
> Cc: omniorb-list at omniorb-support.com, Rene Jager <renej.frog at yucom.be>
> Message-ID: <3FB8FD55.50400 at fourpalms.org>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> >>>would be nice if omniORBpy and pyton-orbit would both have a seperate
> >>>package for the top-level parts (not that I really need it; I only use
> >>>omniORBpy ;-)
> > That is what I suggested the last time this came up...
>
> OK, what should that top-level package be called? I'm willing to do the
> packaging, but need suggestions on a name. Current packages are
>
> omniORBpy
> omniORBpy-devel
> omniORBpy-doc
>
> The top-level namespace involves OMG compliance; could it be called
>
> omniORBpy-omg or omniORBpy-standard or ????
>
> - Tom
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 17 Nov 2003 19:04:21 +0100
> From: "Renzo Tomaselli" <renzo.tomaselli at tecnotp.it>
> Subject: Re: [omniORB] invalid warning while destroying compound
> DynAnys
> To: "Duncan Grisby" <duncan at grisby.org>
> Cc: Omniorb list <omniorb-list at omniorb-support.com>
> Message-ID: <05aa01c3ad35$e5124e80$250f0aa2 at Renzo>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Duncan,
> it's faster to tell you what happens from my debugger.
> When a top level DynAny is finally destroyed, it calls
> DynAnyConstrBase::onDispose(), which in turn invokes detach() on each
> component. This methods simply sets pd_is_root = 1.
> Then, when the component itself is destroyed, we get the warning.
> I tracked this down while monitoring a DynStruct.
> Cheers,
>
> Renzo
>
> ----- Original Message -----
> From: "Duncan Grisby" <duncan at grisby.org>
> To: "Renzo Tomaselli" <renzo.tomaselli at tecnotp.it>
> Cc: "Omniorb list" <omniorb-list at omniorb-support.com>
> Sent: Monday, November 17, 2003 1:49 PM
> Subject: Re: [omniORB] invalid warning while destroying compound DynAnys
>
>
> > On Friday 14 November, "Renzo Tomaselli" wrote:
> >
> > > while destroying compound DynAnys, we get a warning (if trace level
> is
> > > 25) from dynAny.cc, line#323.
> > > This warning occurs at each nested component since it appears to have
> > > pd_is_root == 1, while (I guess) this should be true only for the top
> level
> > > DynAny (e.g. the container).
> >
> > Yes, pd_is_root should only be true for the top level DynAny. Can you
> > provide some (minimal) example code that exhibits the problem?
> >
> > Cheers,
> >
> > Duncan.
> >
> > --
> > -- Duncan Grisby --
> > -- duncan at grisby.org --
> > -- http://www.grisby.org --
> >
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 17 Nov 2003 19:08:54 +0100
> From: "Renzo Tomaselli" <renzo.tomaselli at tecnotp.it>
> Subject: Re: [omniORB] AIX: pure virtual method called
> To: "Omniorb list" <omniorb-list at omniorb-support.com>
> Message-ID: <05ab01c3ad35$e57d4550$250f0aa2 at Renzo>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi all,
> this issue seems to be fully solved by the latest g++ version (3.3.2),
> plus all fixpacks concerning AIX. Now our entire application runs fine on
> AIX 5.2 with OmniORB 4.02.
> Cheers,
>
> Renzo
>
> ----- Original Message -----
> From: "Renzo Tomaselli" <renzo.tomaselli at tecnotp.it>
> To: "Omniorb list" <omniorb-list at omniorb-support.com>
> Sent: Wednesday, November 12, 2003 12:22 PM
> Subject: [omniORB] AIX: pure virtual method called
>
>
> > Hi,
> > we just ported our architecture to AIX 5.2 through g++ 3.3.1, while
> > OmniORB version is 4.02, standard sources. The same runs fine on Windows
> > (msvc 6.0), Solaris (g++ 3.2.3), Linux (3.2.0).
> > Apparently everything was ok on AIX too, but then we got random failures
> > after throwing user exceptions. In short, an user exception is thrown from
> a
> > servant (say throw NotFound()) and caught by the caller in the same
> process
> > (although in a different shlib).
> ...
>
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 17 Nov 2003 19:52:17 +0100
> From: "JHJE (Jan Holst Jensen)" <jhje at novonordisk.com>
> Subject: RE: [omniORB] omniName GUI
> To: <omniorb-list at omniorb-support.com>
> Message-ID:
> <45C04601B80F0E49B49D5434521C12D601287636 at exdkba023.novo.dk>
> Content-Type: text/plain; charset="us-ascii"
>
> > Date: Mon, 17 Nov 2003 11:35:57 +0100
> > From: "FredP" <frederic.prin at silvaco.com>
> > Subject: [omniORB] omniName GUI
> >
> > Hi all,
> >
> > Is there someone who knows a graphical tool that can display
> > the internal table of omniNames bindings graph ?
> >
> > TIA
> >
> > FredP
>
> If you are satisfied with a Windows-only tool I can send you a binary
> that I use myself. Has some rudimentary admin facilities as well that I
> put in. Should work with any Interoperable Naming Service. Works well
> with omniNames at least.
>
> Cheers
>
> -- Jan Holst Jensen, Novo Nordisk A/S, Denmark
>
>
> ------------------------------
>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list
>
>
> End of omniORB-list Digest, Vol 7, Issue 20
> *******************************************
>
More information about the omniORB-list
mailing list