[.NET Remoting] Nagaan 'hoe' een method aangeroepen wordt.

[whoami]

Ik heb ff een kort vraagje:

Is het mogelijk om na te gaan of een bepaalde method van een class die remote-able is (inherit van MarshallByRefObj) aangeroepen werd via remoting of 'gewoon' gecalled werd ?

Voorbeeldje:

code:

class MyRemObj : MarshalByRefObj
{

    public void Miep()
    {
         //
    }

}

Stel bovenstaande class.
Nu wil ik in de method 'Miep' checken of die method via een remote call aangeroepen werd, of gewoon aangeroepen werd...

[Alarmnummer]

Misschien kan je zo`n noodoplossing gebruiken (alleen voor het debuggen)

code:

try{
   throw new Exception();
}catch(Exception ex){
   ex.printStacktrace();
}

[ Voor 10% gewijzigd door Alarmnummer op 19-05-2005 09:44 ]

[whoami]

Alarmnummer schreef op donderdag 19 mei 2005 @ 09:43:
Misschien kan je zo`n noodoplossing gebruiken (alleen voor het debuggen)

code:

try{
   throw new Exception();
}catch(Exception ex){
   ex.printStacktrace();
}

Hmm, niet echt.
Als m'n method via remoting aangeroepen werd, dan wil ik nl. iets extra's ondernemen....

[Alarmnummer]

whoami schreef op donderdag 19 mei 2005 @ 09:44:
[...]
Hmm, niet echt.
Als m'n method via remoting aangeroepen werd, dan wil ik nl. iets extra's ondernemen....

Je hebt toch controle als een remote call bij je objecten aankomt? Eventueel met een proxy/decorator of anders gewoon een parameter: remote

[whoami]

Alarmnummer schreef op donderdag 19 mei 2005 @ 09:49:
[...]

Je hebt toch controle als een remote call bij je objecten aankomt? Eventueel met een proxy/decorator of anders gewoon een parameter: remote

Mja, voorlopig heb ik het gewoon met een parameter opgelost, maar, indien het mogelijk is, zou ik het graag achter de schermen kunnen doen.

[MSalters]

Ergens heb ik het gevoel dat je dat niet moet willen. Als een functie twee verschillende effecten heeft, dan zouden het twee functies moeten zijn.

[Alarmnummer]

whoami schreef op donderdag 19 mei 2005 @ 09:50:
Mja, voorlopig heb ik het gewoon met een parameter opgelost, maar, indien het mogelijk is, zou ik het graag achter de schermen kunnen doen.

Kan je niet een principal binden aan de threadlocal en daar een LocalPrincipal en een RemotePrincipal van aan koppelen. Bij een remoteverbiding staat dan een RemotePrincipal klaar en bij een locale verbinding een LocalPrincipal.

MSalters schreef op donderdag 19 mei 2005 @ 09:55:
Ergens heb ik het gevoel dat je dat niet moet willen. Als een functie twee verschillende effecten heeft, dan zouden het twee functies moeten zijn.

Ik weet niet precies wat zijn eisen zijn, maar soms is het handig dat dit transparant gebeurt.

[ Voor 42% gewijzigd door Alarmnummer op 19-05-2005 10:07 ]

[whoami]

MSalters schreef op donderdag 19 mei 2005 @ 09:55:
Ergens heb ik het gevoel dat je dat niet moet willen. Als een functie twee verschillende effecten heeft, dan zouden het twee functies moeten zijn.

Mja, eigenlijk heb je gelijk.
Echter, 'verschillende effecten' is in dit geval misschien een beetje 'overdreven'.
Als die method via een remote-call aangeroepen wordt, dan wil ik gewoon dat de taak die die method moet uitvoeren op een andere thread gestart wordt.

[whoami]

Alarmnummer schreef op donderdag 19 mei 2005 @ 10:04:
[...]

Kan je niet een principal binden aan de threadlocal en daar een LocalPrincipal en een RemotePrincipal van aan koppelen. Bij een remoteverbiding staat dan een RemotePrincipal klaar en bij een locale verbinding een LocalPrincipal.

Nee, dat zal ik niet kunnen doen.
De 'WindowsPrincipal' wordt al doorgegeven, en die heb ik nodig.

[Alarmnummer]

whoami schreef op donderdag 19 mei 2005 @ 10:07:
[...]


Mja, eigenlijk heb je gelijk.
Echter, 'verschillende effecten' is in dit geval misschien een beetje 'overdreven'.
Als die method via een remote-call aangeroepen wordt, dan wil ik gewoon dat de taak die die method moet uitvoeren op een andere thread gestart wordt.

Kan je dan niet gewoon die call helemaal ontkoppelen van de implementatie? Zo los ik dit soort dingen wel op.. met asynchrone communicatie zijn er andere mogelijkheden en daar wil ik dan ook gebruik van kunnen maken en dat zijn mogelijkheden die een synchrone interface me niet bied.

code:

interface AsynchronousFooService{
     Future execute(FooJob job);
}

interface FooService{
     void execute(FooJob job);
}

class AsynchronousFooServicImpl implements AsynchronousFooService{


     AsynchronousFooServicImpl (ExecutorService executorService, FooService fooService){
           _fooService= fooService;
           _executorService= executorService;
     }

     Future execute(FooJob job){
        return  _executorService.submit(new RunnableImpl(job));
     }

    class RunnableImpl implements Runnable{
       RunnableImpl(FooJob job)
          _job =job;
       }

        void run(){
              _fooService.execute(job);
         }
     }
}

Op deze manier (via de ExecutorService) hou je ook controle hoeveel threads er woren opgestart.. Als jij zo maar threads opstart bij iedere remote call kun je diep in de problemen komen.

[edit]
En voor de liefhebbers: dit is weer een prachtig voorbeeldje van Inversion of Control (IOC)

[ Voor 61% gewijzigd door Alarmnummer op 19-05-2005 10:36 ]

[dotcode]

Volgens mij moet je even kijken in:

System.Diagnostics.Debug

Namespace, met de debugger kan je zo de call stack ophalen. En nog meer info...