orbit-python-list

[Orbit-python-list] orbit-python and __setattr__ overloading

[Marcelo CB <co...@as...>]

Hi,

I noticed that when overloading __setattr__ for ORBit classes, I wont get
the attributes handled by orbit-python, what means it handles the class
__dict__ directly at server side, right ? 

I was wondering if this is an expected behaviour, mostly because I would
like to overload __setattr__ to know when an attribute was changed. I need
this to control the persistency state of the class.

one workaround I can think of ( and I am actually using it ) is to
implement myself methods to set each attribute (setAttrib1, setAttrib2, or
set_attrib1, set__attrib2), and then take whatever action I would
like before setting the attribute.

I could also use a 'set' method, so I would do set('attrib','value'), but
none of this would be as elegant as overloading __setattr__ and catching
attribute changes transparently.

Am I crazy, or blind, not to see a better option ?

is it possible that orbit-python would set the attribites through
__setattr__ the way I though so  could overload it ?

sorry for the long msg, and thanks.


-------------------------------------------------------------------
Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Roland M. <ma...@ec...>]

Marcelo CB (2001-01-30 16:43:29 -0200) :

> I was wondering if this is an expected behaviour, mostly because I
> would like to overload __setattr__ to know when an attribute was
> changed. I need this to control the persistency state of the class.

  I think I coded that sometime last summer.  You just have to use the
correct method names, namely _get_<attributename> and
_set_<attributename>.

Roland.
-- 
Roland Mas

C r  ' s  d   a  u    e   e    ll r   a  u i r .  
  -- Signatures à collectionner, série n°1, partie 1/3.

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Marcelo CB <co...@as...>]

thanks, it just worked as expected!

_set_<attribname>



On 30 Jan 2001, Roland Mas wrote:

> Marcelo CB (2001-01-30 16:43:29 -0200) :
>=20
> > I was wondering if this is an expected behaviour, mostly because I
> > would like to overload __setattr__ to know when an attribute was
> > changed. I need this to control the persistency state of the class.
>=20
>   I think I coded that sometime last summer.  You just have to use the
> correct method names, namely _get_<attributename> and
> _set_<attributename>.
>=20
> Roland.
> --=20
> Roland Mas
>=20
> C r  ' s  d   a  u    e   e    ll r   a  u i r . =20
>   -- Signatures =E0 collectionner, s=E9rie n=B01, partie 1/3.
>=20
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbit-python-list
>=20

Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Jason T. <ta...@li...>]

> Hi,

Hi Marcelo,

> is it possible that orbit-python would set the attribites through
> __setattr__ the way I though so  could overload it ?

Keep in mind that ORBit-Python's transparent handling of attributes is
not really part of the mapping spec, and there are some good reasons to
avoid using them (such as explicitness).  I personally like the idea of
transparency, though.

At the moment, ORBit-Python won't call the servant's __setattr__ and
__getattr__ functions on invocation of one of the attribute accessor
functions.  It obviously should.  I expect that's an easy thing to fix,
so I'll do that right now.  (Stay tuned.)

As an alternative, you could override the accessor function, which is
what you're supposed to do anyway (if you want to be compliant with the
mapping spec).  So for example:

interface Foo {
   attribute string mystr;
};

Then in the implementation:

class Foo_Impl(Global__POA.Foo):
   def _set_mystr(self, val):
      print "Setting mystr attribute"
      self.mystr = val

   def _get_mystr(self):
      print "Getting mystr attribute"
      return self.mystr

Anyway, I'll commit a fix for ORBit-Python to call __setattr__ and
__getattr__ for the servant in the absence of an implemented accessor
function.

Cheers,
Jason.

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Marcelo CB <co...@as...>]

Hi Jason,

You're right, after Roland's post I realized that the right thing to do
was to overload the _set_'s and _get_'s instead of __setattr__ so I don't
have to check if the attributes being changed are critical to the
persistency or not. I just override the correct arguments.

thanks.

On Tue, 30 Jan 2001, Jason Tackaberry wrote:

> > Hi,
> 
> Hi Marcelo,
> 
> > is it possible that orbit-python would set the attribites through
> > __setattr__ the way I though so  could overload it ?
> 
> Keep in mind that ORBit-Python's transparent handling of attributes is
> not really part of the mapping spec, and there are some good reasons to
> avoid using them (such as explicitness).  I personally like the idea of
> transparency, though.
> 
> At the moment, ORBit-Python won't call the servant's __setattr__ and
> __getattr__ functions on invocation of one of the attribute accessor
> functions.  It obviously should.  I expect that's an easy thing to fix,
> so I'll do that right now.  (Stay tuned.)
> 
> As an alternative, you could override the accessor function, which is
> what you're supposed to do anyway (if you want to be compliant with the
> mapping spec).  So for example:
> 
> interface Foo {
>    attribute string mystr;
> };
> 
> Then in the implementation:
> 
> class Foo_Impl(Global__POA.Foo):
>    def _set_mystr(self, val):
>       print "Setting mystr attribute"
>       self.mystr = val
> 
>    def _get_mystr(self):
>       print "Getting mystr attribute"
>       return self.mystr
> 
> Anyway, I'll commit a fix for ORBit-Python to call __setattr__ and
> __getattr__ for the servant in the absence of an implemented accessor
> function.
> 
> Cheers,
> Jason.
> 
> _______________________________________________
> Orbit-python-list mailing list
> Orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbit-python-list
> 

Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Jason T. <ta...@li...>]

> was to overload the _set_'s and _get_'s instead of __setattr__ so I don't
> have to check if the attributes being changed are critical to the
> persistency or not. I just override the correct arguments.

That said, __setattr__ and __getattr__ *should* be handled properly
anyway, so I've committed an update for this.

Unfortunately, SourceForge's anoncvs server is being weird right now (is
it broken for anyone else too?), so I've attached the patch to this
email (patches server.c).

Jason.

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Marcelo CB <co...@as...>]

I couldn't update, but checkout worked properly. Got the patch, will try
it out.

On Tue, 30 Jan 2001, Jason Tackaberry wrote:

> > was to overload the _set_'s and _get_'s instead of __setattr__ so I don't
> > have to check if the attributes being changed are critical to the
> > persistency or not. I just override the correct arguments.
> 
> That said, __setattr__ and __getattr__ *should* be handled properly
> anyway, so I've committed an update for this.
> 
> Unfortunately, SourceForge's anoncvs server is being weird right now (is
> it broken for anyone else too?), so I've attached the patch to this
> email (patches server.c).
> 
> Jason.
> 

Marcelo Corbani de Barros                   co...@as...
Async Open Source Development - Brasil

Re: [Orbit-python-list] orbit-python and __setattr__ overloading

[Jason T. <ta...@li...>]

> I couldn't update, but checkout worked properly. Got the patch, will try
> it out.

How bizarre.  Well if it checked out okay, you won't need to apply the
patch (since I was able to commit it fine).

Jason.

[Orbit-python-list] Exiting Corba Server app

[Christian R. R. <ki...@as...>]

Hi, sorry for the crosspost but perhaps someone on the main list knows
something I don't.

I now wonder what's the proper way to shut down a corba application
server? I'm using orbit-python, and I've noticed the following problem:

I can't kill my server gracefully. I can't shut down my database
connections, and I can't flush my files. Why?

a) I can exit using Ctrl-\ or Ctrl-Z + kill %. This works, but since I
can't catch signals inside my corba app, it isn't a graceful exit and
everything is left pending. I understand daemons are supposed to be killed
with signals, but orbit-python won't let me do it unless I hack the source
code unconventionally.

b) I could exit by receiving a corba request. However, orbit won't shut
down when processing a client request (or it does, but breaks the
marshalling). Ok, so I can close files and connections and just break, but
it's a bit ugly, no?

c) I guess I could receive a request and set an alarm.. but wait, I can't
handle signals. Jeez.

Any help?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Orbit-python-list] Re: Exiting Corba Server app

[Elliot L. <so...@re...>]

On Thu, 15 Feb 2001, Christian Robottom Reis wrote:

> Hi, sorry for the crosspost but perhaps someone on the main list knows
> something I don't.
>
> I now wonder what's the proper way to shut down a corba application
> server? I'm using orbit-python, and I've noticed the following problem:
>
> I can't kill my server gracefully. I can't shut down my database
> connections, and I can't flush my files. Why?

Your app needs to call CORBA_ORB_shutdown (or orb.shutdown(), or whatever
the python bindings use). When your app makes that call is entirely Your
Problem.

-- Elliot
Who me? I just wander from room to room.