Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Inheritance & Intercomponent calls

8 posts in General Discussion (old) Last posting was on 2000-02-15 10:01:24.0Z
Phil Ruelle Posted on 2000-02-11 09:18:13.0Z
Newsgroups: sybase.public.easerver
From: "Phil Ruelle" <no_spam_philr@iplbath.com>
Subject: Inheritance & Intercomponent calls
Date: Fri, 11 Feb 2000 09:18:13 -0000
Lines: 52
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
NNTP-Posting-Host: h1.iplbath.com 195.153.211.7
Message-ID: <347_k0Ay3FHd$GA.184@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28917
Article PK: 161287

Be warned, this is a REAL challenge!

We have a problem concerning inheritance of Jaguar objects and their use in
inter-component calls that seems insurmountable. Can anyone confirm or deny
this? Here we go:

All our server side objects inherit from a common, non-deployed base object
which we'll call base_impl. Suppose we have a derived class, inherited_impl
which derives directly from base_impl.

When we deploy the derived object to the server we change its deployed name
to
inherited. The reason for this name change is to allow us to make
inter-component calls using the PROXY for the derived object rather than the
'real' derived object.

This all sounds great but when proxies are generated for inherited, a proxy
is
also generated for base_impl (quite reasonable since that is the object it
inherits from). The problem is that when the inherited proxy is used by a
server-side component the proxy for base_impl clashes with the 'real'
base_impl - the same problem we solved for the earlier for the derived
object
by changing its name on deployment.

We tried moving the proxy for base_impl into a seperate library that
server-side objects do not access but the problem with that is our inherited
proxy will actually be derived from the 'real' base_impl and not from a
proxy
(this then prevents non-overridden base class functions being called
correctly
and prevents overridden base class functions being called with Null
parameters).

We've tried explicitly deploying base_impl as base (which we'd really rather
avoid), hoping that the proxy for inherited_impl use that as its base class
rather than base_impl but to no avail.

Does anyone know how to generate (or hack!) a complete, non-clashing
hierarchy
of proxies e.g.
Proxies - base, inherited
'Real' objects - base_impl, derived_impl
or is this something we're stuck with and have to design around?

TIA,

Phil Ruelle


Peter Annaert Posted on 2000-02-14 16:53:50.0Z
Newsgroups: sybase.public.easerver
Reply-To: "Peter Annaert" <peter.annaert@sofico.be>
From: "Peter Annaert" <peter.annaert@sofico.be>
Subject: Re: Inheritance & Intercomponent calls
Date: Mon, 14 Feb 2000 17:53:50 +0100
Lines: 80
Organization: Sofico N.V.
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
NNTP-Posting-Host: uu194-7-38-106.unknown.uunet.be 194.7.38.106
Message-ID: <347_hgOheuwd$GA.327@forums.sybase.com>
References: <347_k0Ay3FHd$GA.184@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28746
Article PK: 160865

Hi,

We are dealing with the same problem!
Unforunately, it's not solved yet. But there MUST BE a solution since we
kind of stole the idea from the DDS EAF framework.
This framework also uses a common ancestor for their interface managers (IM)
and business objects (BO).

Anyway, success in your attempt to make a working application server with
EAS!

Peter Annaert,

Phil Ruelle <no_spam_philr@iplbath.com> wrote in message
news:k0Ay3FHd$GA.184@forums.sybase.com...
> Be warned, this is a REAL challenge!
>
> We have a problem concerning inheritance of Jaguar objects and their use
in
> inter-component calls that seems insurmountable. Can anyone confirm or
deny
> this? Here we go:
>
> All our server side objects inherit from a common, non-deployed base
object
> which we'll call base_impl. Suppose we have a derived class,
inherited_impl
> which derives directly from base_impl.
>
> When we deploy the derived object to the server we change its deployed
name
> to
> inherited. The reason for this name change is to allow us to make
> inter-component calls using the PROXY for the derived object rather than
the
> 'real' derived object.
>
> This all sounds great but when proxies are generated for inherited, a
proxy
> is
> also generated for base_impl (quite reasonable since that is the object it
> inherits from). The problem is that when the inherited proxy is used by a
> server-side component the proxy for base_impl clashes with the 'real'
> base_impl - the same problem we solved for the earlier for the derived
> object
> by changing its name on deployment.
>
> We tried moving the proxy for base_impl into a seperate library that
> server-side objects do not access but the problem with that is our
inherited
> proxy will actually be derived from the 'real' base_impl and not from a
> proxy
> (this then prevents non-overridden base class functions being called
> correctly
> and prevents overridden base class functions being called with Null
> parameters).
>
> We've tried explicitly deploying base_impl as base (which we'd really
rather
> avoid), hoping that the proxy for inherited_impl use that as its base
class
> rather than base_impl but to no avail.
>
> Does anyone know how to generate (or hack!) a complete, non-clashing
> hierarchy
> of proxies e.g.
> Proxies - base, inherited
> 'Real' objects - base_impl, derived_impl
> or is this something we're stuck with and have to design around?
>
> TIA,
>
> Phil Ruelle
>
>
>
>


Dean Jones [Team Sybase] Posted on 2000-02-11 15:35:43.0Z
Newsgroups: sybase.public.easerver
Reply-To: "Dean Jones [Team Sybase]" <nospam_dean@powerobjects.com>
From: "Dean Jones [Team Sybase]" <nospam_dean@powerobjects.com>
Subject: Re: Inheritance & Intercomponent calls
Date: Fri, 11 Feb 2000 09:35:43 -0600
Lines: 82
Organization: PowerTeam, Inc.
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
NNTP-Posting-Host: modem16.outtech.com 216.207.144.246
Message-ID: <347_KGHCtVKd$GA.305@forums.sybase.com>
References: <347_k0Ay3FHd$GA.184@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28895
Article PK: 161269

Your right this is confusing. <g>

Lets break it down. Are you basically saying you are trying to develop an
abstract layer, so you inter-component calls go against the abstract layer
without consideration for the actual component processing the request? Does
that make since?

--
Dean Jones, CPD Professional
Team Sybase
dean@powerobjects.com

PowerTeam, Inc.
http://www.powerobjects.com

Phil Ruelle <no_spam_philr@iplbath.com> wrote in message
news:k0Ay3FHd$GA.184@forums.sybase.com...
> Be warned, this is a REAL challenge!
>
> We have a problem concerning inheritance of Jaguar objects and their use
in
> inter-component calls that seems insurmountable. Can anyone confirm or
deny
> this? Here we go:
>
> All our server side objects inherit from a common, non-deployed base
object
> which we'll call base_impl. Suppose we have a derived class,
inherited_impl
> which derives directly from base_impl.
>
> When we deploy the derived object to the server we change its deployed
name
> to
> inherited. The reason for this name change is to allow us to make
> inter-component calls using the PROXY for the derived object rather than
the
> 'real' derived object.
>
> This all sounds great but when proxies are generated for inherited, a
proxy
> is
> also generated for base_impl (quite reasonable since that is the object it
> inherits from). The problem is that when the inherited proxy is used by a
> server-side component the proxy for base_impl clashes with the 'real'
> base_impl - the same problem we solved for the earlier for the derived
> object
> by changing its name on deployment.
>
> We tried moving the proxy for base_impl into a seperate library that
> server-side objects do not access but the problem with that is our
inherited
> proxy will actually be derived from the 'real' base_impl and not from a
> proxy
> (this then prevents non-overridden base class functions being called
> correctly
> and prevents overridden base class functions being called with Null
> parameters).
>
> We've tried explicitly deploying base_impl as base (which we'd really
rather
> avoid), hoping that the proxy for inherited_impl use that as its base
class
> rather than base_impl but to no avail.
>
> Does anyone know how to generate (or hack!) a complete, non-clashing
> hierarchy
> of proxies e.g.
> Proxies - base, inherited
> 'Real' objects - base_impl, derived_impl
> or is this something we're stuck with and have to design around?
>
> TIA,
>
> Phil Ruelle
>
>
>
>


Phil Ruelle Posted on 2000-02-11 17:40:07.0Z
Newsgroups: sybase.public.easerver
From: "Phil Ruelle" <no_spam_philr@iplbath.com>
Subject: Re: Inheritance & Intercomponent calls
Date: Fri, 11 Feb 2000 17:40:07 -0000
Lines: 103
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
NNTP-Posting-Host: h1.iplbath.com 195.153.211.7
Message-ID: <347_CKUnWeLd$GA.180@forums.sybase.com>
References: <347_k0Ay3FHd$GA.184@forums.sybase.com> <347_KGHCtVKd$GA.305@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28887
Article PK: 161262


>Lets break it down. Are you basically saying you are trying to develop an
>abstract layer, so you inter-component calls go against the abstract layer
>without consideration for the actual component processing the request? Does
>that make since?

I think I follow what you're saying but that isn't quite what I'm attempting
to do. I want a hierarchy of proxies where each proxy corresponds to a (part
of) a deployed object.
Let me have another go at explaining it.

Suppose I have two server components (comp1_impl and comp2_impl) in a
library and I want comp1_impl to use comp2_impl. I can deploy comp2_impl to
Jaguar with the name comp2, generate a proxy for it and then use that for
inter-component calls.

That's the correct thing to do, right?

Okay, so suppose comp2_impl actually inherits from base_impl. When I deploy
comp2_impl and generate a proxy for it I actually get two proxies - one for
comp2 and one for base_impl. If I now include the proxy library in my
application the proxy defintion of base_impl clashes with the real
definition of it.

All our problems stem from this. In an ideal world we'd like to deploy
comp2_impl, and when we generate a proxy we'd like to get two proxies - base
and comp2, where comp2 inherits from base. We could then create a proxy for
comp2, call a base class function and have the function
execute on the deployed comp2 object.

Hope that's a bit clearer. If anything needs clarification (most of it!) let
me know.
Thanks for looking at this,

Phil Ruelle


>> Be warned, this is a REAL challenge!
>>
>> We have a problem concerning inheritance of Jaguar objects and their use
>in
>> inter-component calls that seems insurmountable. Can anyone confirm or
>deny
>> this? Here we go:
>>
>> All our server side objects inherit from a common, non-deployed base
>object
>> which we'll call base_impl. Suppose we have a derived class,
>inherited_impl
>> which derives directly from base_impl.
>>
>> When we deploy the derived object to the server we change its deployed
>name
>> to
>> inherited. The reason for this name change is to allow us to make
>> inter-component calls using the PROXY for the derived object rather than
>the
>> 'real' derived object.
>>
>> This all sounds great but when proxies are generated for inherited, a
>proxy
>> is
>> also generated for base_impl (quite reasonable since that is the object
it
>> inherits from). The problem is that when the inherited proxy is used by a
>> server-side component the proxy for base_impl clashes with the 'real'
>> base_impl - the same problem we solved for the earlier for the derived
>> object
>> by changing its name on deployment.
>>
>> We tried moving the proxy for base_impl into a seperate library that
>> server-side objects do not access but the problem with that is our
>inherited
>> proxy will actually be derived from the 'real' base_impl and not from a
>> proxy
>> (this then prevents non-overridden base class functions being called
>> correctly
>> and prevents overridden base class functions being called with Null
>> parameters).
>>
>> We've tried explicitly deploying base_impl as base (which we'd really
>rather
>> avoid), hoping that the proxy for inherited_impl use that as its base
>class
>> rather than base_impl but to no avail.
>>
>> Does anyone know how to generate (or hack!) a complete, non-clashing
>> hierarchy
>> of proxies e.g.
>> Proxies - base, inherited
>> 'Real' objects - base_impl, derived_impl
>> or is this something we're stuck with and have to design around?
>>
>> TIA,
>>
>> Phil Ruelle
>>
>>
>>
>>
>
>


Scott McReynolds [Sybase] Posted on 2000-02-11 18:43:14.0Z
Newsgroups: sybase.public.easerver
From: "Scott McReynolds [Sybase]" <scottmc@sybase.com>
Subject: Re: Inheritance & Intercomponent calls
Date: Fri, 11 Feb 2000 11:43:14 -0700
Lines: 131
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
NNTP-Posting-Host: scottmc-pc.sybase.com 157.133.56.75
Message-ID: <347_qoMVUBMd$GA.96@forums.sybase.com>
References: <347_k0Ay3FHd$GA.184@forums.sybase.com> <347_KGHCtVKd$GA.305@forums.sybase.com> <347_CKUnWeLd$GA.180@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28880
Article PK: 161255

Phil,

you are going about this the right way, but the best way around this problem
is to append the jaguar package to the proxies. This will serve to solve 2
problems, one is the problem you have described about PB getting confussed
about what the NVO is inherting from. The other problem it solves is that
jaguar PBVM will not get confussed about whether it is using the actual NVO
or the proxy to call the second object.

Scott

Phil Ruelle <no_spam_philr@iplbath.com> wrote in message
news:CKUnWeLd$GA.180@forums.sybase.com...
> >Lets break it down. Are you basically saying you are trying to develop an
> >abstract layer, so you inter-component calls go against the abstract
layer
> >without consideration for the actual component processing the request?
Does
> >that make since?
>
> I think I follow what you're saying but that isn't quite what I'm
attempting
> to do. I want a hierarchy of proxies where each proxy corresponds to a
(part
> of) a deployed object.
> Let me have another go at explaining it.
>
> Suppose I have two server components (comp1_impl and comp2_impl) in a
> library and I want comp1_impl to use comp2_impl. I can deploy comp2_impl
to
> Jaguar with the name comp2, generate a proxy for it and then use that for
> inter-component calls.
>
> That's the correct thing to do, right?
>
> Okay, so suppose comp2_impl actually inherits from base_impl. When I
deploy
> comp2_impl and generate a proxy for it I actually get two proxies - one
for
> comp2 and one for base_impl. If I now include the proxy library in my
> application the proxy defintion of base_impl clashes with the real
> definition of it.
>
> All our problems stem from this. In an ideal world we'd like to deploy
> comp2_impl, and when we generate a proxy we'd like to get two proxies -
base
> and comp2, where comp2 inherits from base. We could then create a proxy
for
> comp2, call a base class function and have the function
> execute on the deployed comp2 object.
>
> Hope that's a bit clearer. If anything needs clarification (most of it!)
let
> me know.
> Thanks for looking at this,
>
> Phil Ruelle
>
>
> >> Be warned, this is a REAL challenge!
> >>
> >> We have a problem concerning inheritance of Jaguar objects and their
use
> >in
> >> inter-component calls that seems insurmountable. Can anyone confirm or
> >deny
> >> this? Here we go:
> >>
> >> All our server side objects inherit from a common, non-deployed base
> >object
> >> which we'll call base_impl. Suppose we have a derived class,
> >inherited_impl
> >> which derives directly from base_impl.
> >>
> >> When we deploy the derived object to the server we change its deployed
> >name
> >> to
> >> inherited. The reason for this name change is to allow us to make
> >> inter-component calls using the PROXY for the derived object rather
than
> >the
> >> 'real' derived object.
> >>
> >> This all sounds great but when proxies are generated for inherited, a
> >proxy
> >> is
> >> also generated for base_impl (quite reasonable since that is the object
> it
> >> inherits from). The problem is that when the inherited proxy is used by
a
> >> server-side component the proxy for base_impl clashes with the 'real'
> >> base_impl - the same problem we solved for the earlier for the derived
> >> object
> >> by changing its name on deployment.
> >>
> >> We tried moving the proxy for base_impl into a seperate library that
> >> server-side objects do not access but the problem with that is our
> >inherited
> >> proxy will actually be derived from the 'real' base_impl and not from a
> >> proxy
> >> (this then prevents non-overridden base class functions being called
> >> correctly
> >> and prevents overridden base class functions being called with Null
> >> parameters).
> >>
> >> We've tried explicitly deploying base_impl as base (which we'd really
> >rather
> >> avoid), hoping that the proxy for inherited_impl use that as its base
> >class
> >> rather than base_impl but to no avail.
> >>
> >> Does anyone know how to generate (or hack!) a complete, non-clashing
> >> hierarchy
> >> of proxies e.g.
> >> Proxies - base, inherited
> >> 'Real' objects - base_impl, derived_impl
> >> or is this something we're stuck with and have to design around?
> >>
> >> TIA,
> >>
> >> Phil Ruelle
> >>
> >>
> >>
> >>
> >
> >
>
>


Phil Ruelle Posted on 2000-02-14 16:57:12.0Z
Newsgroups: sybase.public.easerver
From: "Phil Ruelle" <no_spam_philr@iplbath.com>
Subject: Re: Inheritance & Intercomponent calls
Date: Mon, 14 Feb 2000 16:57:12 -0000
Lines: 34
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
NNTP-Posting-Host: h1.iplbath.com 195.153.211.7
Message-ID: <347_DIB3Y0wd$GA.327@forums.sybase.com>
References: <347_k0Ay3FHd$GA.184@forums.sybase.com> <347_KGHCtVKd$GA.305@forums.sybase.com> <347_CKUnWeLd$GA.180@forums.sybase.com> <347_qoMVUBMd$GA.96@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28744
Article PK: 160863

Scott,

I turned on the 'Prepend jaguar package name to object name' property in our
proxy generation project but now when I run our application I get an error
in srv.log:

Feb 14 16:47:40 2000: Exception 'CosNaming::NamingContext::NotFound' in
Session::lookup for component 'movie_package/movie_package_jc_films'
Feb 14 16:47:40 2000: SystemException: OBJECT_NOT_EXIST (Session/lookup -
@127.0.0.1)

It appears that although the proxies now inherit correctly Jaguar can't
resolve them! It only knows about an object called 'jc_films'. Any ideas how
to get around this? I can't believe this option has been provided without it
actually working - what have I missed.

Thanks,

Phil

>Phil,
>
>you are going about this the right way, but the best way around this
problem
>is to append the jaguar package to the proxies. This will serve to solve 2
>problems, one is the problem you have described about PB getting confussed
>about what the NVO is inherting from. The other problem it solves is that
>jaguar PBVM will not get confussed about whether it is using the actual NVO
>or the proxy to call the second object.
>
>Scott


Evan Ireland Posted on 2000-02-14 21:52:14.0Z
Newsgroups: sybase.public.easerver
Date: Tue, 15 Feb 2000 10:52:14 +1300
From: Evan Ireland <eireland@sybase.com>
Organization: Sybase, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Ruelle <no_spam_philr@iplbath.com>
Subject: Re: Inheritance & Intercomponent calls
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 65
NNTP-Posting-Host: 130.214.8.57
Message-ID: <347_38A8790E.4983C465@sybase.com>
References: <347_k0Ay3FHd$GA.184@forums.sybase.com> <347_KGHCtVKd$GA.305@forums.sybase.com> <347_CKUnWeLd$GA.180@forums.sybase.com> <347_qoMVUBMd$GA.96@forums.sybase.com> <347_DIB3Y0wd$GA.327@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28713
Article PK: 160837


Phil Ruelle wrote:
>
> Scott,
>
> I turned on the 'Prepend jaguar package name to object name' property in our
> proxy generation project but now when I run our application I get an error
> in srv.log:
>
> Feb 14 16:47:40 2000: Exception 'CosNaming::NamingContext::NotFound' in
> Session::lookup for component 'movie_package/movie_package_jc_films'
> Feb 14 16:47:40 2000: SystemException: OBJECT_NOT_EXIST (Session/lookup -
> @127.0.0.1)

That indicates good progress. I would always recommend using the
"Prepend Jaguar package name" option for large scale projects, as it protects
you from name collision problems when multiple packages have components with
the same names.

> It appears that although the proxies now inherit correctly Jaguar can't
> resolve them! It only knows about an object called 'jc_films'. Any ideas how
> to get around this? I can't believe this option has been provided without it
> actually working - what have I missed.

I am assuming that the component you are trying to access is named
"movie_package/jc_films". If this is correct it indicates that the client is
trying to lookup the wrong component.

Your client code should look something like:

movie_package_jc_films films
connection.CreateInstance(films, "movie_package/jc_films")

Perhaps you have set the Application property in the Connection object to
"movie_package" when connecting to Jaguar. Please leave that field unset,
since the package name is already specified as the second parameter to
CreateInstance (the Application property is used as a default when the
package name is not specified in the second parameter to CreateInstance).

Perhaps your existing client code reads:

movie_package_jc_films films
connection.CreateInstance(films)

and you have set the Application property to 'movie_package'. If that is the
case, then what you have shown is that "Prepend Jaguar package name" for
proxies and setting the Application property are mutually exclusive.

Anyway, there is a fair bit of speculation above, since we haven't seen
your client code. Please post a fragment of your existing client code. I
think that we should ascertain if there are usability issues with
CreateInstance that we could address to make things easier in future.
________________________________________________________________________________

Evan Ireland Sybase EA Server Engineering eireland@sybase.com
Wellington - New Zealand +64 4 934-5856


Phil Ruelle Posted on 2000-02-15 10:01:24.0Z
Newsgroups: sybase.public.easerver
From: "Phil Ruelle" <no_spam_philr@iplbath.com>
Subject: Re: Inheritance & Intercomponent calls
Date: Tue, 15 Feb 2000 10:01:24 -0000
Lines: 15
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
NNTP-Posting-Host: h1.iplbath.com 195.153.211.7
Message-ID: <347_Zk3wuw5d$GA.324@forums.sybase.com>
References: <347_k0Ay3FHd$GA.184@forums.sybase.com> <347_KGHCtVKd$GA.305@forums.sybase.com> <347_CKUnWeLd$GA.180@forums.sybase.com> <347_qoMVUBMd$GA.96@forums.sybase.com> <347_DIB3Y0wd$GA.327@forums.sybase.com> <347_38A8790E.4983C465@sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28674
Article PK: 160804

Evan,

You were spot on, I had set the application property of the connection
object and my code was exactly as you guessed. Everything now works fine.

Thanks a lot. Your help is greatly appreciated, as is that of Scott, Dean
and everyone else on this group.

Cheers,

Phil Ruelle