Debugging across eSpaces does not always work?

Debugging across eSpaces does not always work?

  
Something that has been bugging me for a while, is debugging across multiple eSpaces. Here is what I usually do:

1. Set a breakpoint in the producer espace.
2. Tell the producer espace to "Debug in Public Area"
3. Tell the consumer espace to "Debug in Public Area"
4. Do actions that should cause the breakpoint to be hit.

Sometimes this works, sometimes this does not work.

Any clues or hints to getting this to work all the time?

Thanks!

J.Ja
Justin James wrote:
Something that has been bugging me for a while, is debugging across multiple eSpaces. Here is what I usually do:

1. Set a breakpoint in the producer espace.
2. Tell the producer espace to "Debug in Public Area"
3. Tell the consumer espace to "Debug in Public Area"
4. Do actions that should cause the breakpoint to be hit.

Sometimes this works, sometimes this does not work.

Any clues or hints to getting this to work all the time?

Thanks!

J.Ja
 
 Hi Justin,

don't forget to set the Entry eSpace, on consumer, by going to (v7.0) Debugger -> Select Entry eSpace.

cheers,
Miguel
This is the same in v6.0
Thanks! I'll give that a shot and see if it is what I am missing!

J.Ja
Justin James wrote:
Something that has been bugging me for a while, is debugging across multiple eSpaces. Here is what I usually do:

1. Set a breakpoint in the producer espace.
2. Tell the producer espace to "Debug in Public Area"
3. Tell the consumer espace to "Debug in Public Area"
4. Do actions that should cause the breakpoint to be hit.

Sometimes this works, sometimes this does not work.

Any clues or hints to getting this to work all the time?

Thanks!

J.Ja
 
 I have also found that it usually doesn't work unless you create a solution combining all of the apps you want to debug together first.
- gerry
Well, I tried the "Set Entry eSpace" and it still is not working reliably. :(

Is there anything else I should be trying?

J.Ja
Justin James wrote:
Well, I tried the "Set Entry eSpace" and it still is not working reliably. :(

Is there anything else I should be trying?

J.Ja
 
 Create a solution with all of the espaces you want to debug across. Then set entry espace and try to debug.
They already are in the same solution. :(

J.Ja
Hi ,

Though i tried the same on version 9.0.0.36 stilll its not working. do you have any clues/hint on this.
Over the weekend I was running into a weird problem and used the debugger in this manner and it didn't work for me either.  One eSpace has the screen and calls an action in the other eSpace which has the breakpoint.  It never stops even though I have verified that the action was called.  Not critical for me anymore but since this goes back three years it would be good to either (a) document the steps to make this work or (b) correct it so it works the same as it does in a single eSpace.

Curt
Curt,

It may help to first have a breakpoint in the first eSpace (just before it calls the second), then select the first eSpace as entry eSpace in the second eSpace, start debugging the second eSpace and set a break point, and continue debugging. This *might* work, though I've had situations that even that didn't result in success.
I've also experienced this situation when debugging multiple espaces.
Do all the steps mentioned in this reply in this thread:
http://www.outsystems.com/forums/discussion/9314/debugging-across-espaces-does-not-always-work/?utm_source=community&utm_medium=email&utm_campaign=weekly-digest#Post29729
----
But also, make sure the consumer espace has updated references to the producer espace. If necessary publish the consumer espace.
---
This has worked with me.
As Tiago said, keeping the references updated between consumer and producer it's vital, it wont work any other way.

Best regards,
PC

I tried all the steps as mentioned above and always get an error message popup saying . below message copy form popup.  Really not sure whats the issue is with communication between two espaces.

P.S: this is the common message I get for all espaces, when  the moment i specify the entry espace name and try to start debug in public area.

[Window Title]
1-Click Publish required
 
[Main Instruction]
Cannot debug your eSpace due to communication problems. Please verify that this eSpace is published and try to start the debugger again.
 
 
 
 
[Buttons]
   [Header=Cl_ose, Content=] 
 
Sugappa Badiger,
The message "Cannot debug your eSpace due to communication problems. (...)" doesn't seem to have anything to do with the problem in this thread: "Debugging across eSpaces".
Have you ever been able to debug (or even publish) just one espace? If not, then you have to solve those communication problems first.

Sugappa Badiger wrote:

I tried all the steps as mentioned above and always get an error message popup saying . below message copy form popup.  Really not sure whats the issue is with communication between two espaces.

P.S: this is the common message I get for all espaces, when  the moment i specify the entry espace name and try to start debug in public area.

[Window Title]
1-Click Publish required
 
[Main Instruction]
Cannot debug your eSpace due to communication problems. Please verify that this eSpace is published and try to start the debugger again.
 
 
 
 
[Buttons]
   [Header=Cl_ose, Content=] 
 
 
 
Hi Tiago Bernardo,

Yes, i am able to debug the single espace properly. when try to link entry espace in producer, then this error will start poping up. though my whole solution is published successfully with resolving all broken/oudated references.

Thank you for the response.
Hello people,

How about debugging in a 3+ levels of espaces?

This is the scenario:
1. Front-end espace A has a Screen Action that triggers an Action in the espace B
2. The action in B triggers an Action in the espace C
3. It's impossible to debub the Action in C.

Had someone experienced this?
João Melo wrote:
Hello people,

How about debugging in a 3+ levels of espaces?

This is the scenario:
1. Front-end espace A has a Screen Action that triggers an Action in the espace B
2. The action in B triggers an Action in the espace C
3. It's impossible to debub the Action in C.

Had someone experienced this?
 Joao -

In C, set "entry espace" to A and turn on debugger, that works for me.

?J.Ja
Thanks again Justin. That is what I was expecting. But A didn't appear in the entry espaces list in C. I realized (just a few minutes ago) that A didn't consume C. So what I had to do was to create a 'fake' reference from A to C (some action for example). So, now A consumes C and appears in the list, and I can debug now. Not the perfect solution, but it works.
Nice discussion
João Melo wrote:
Thanks again Justin. That is what I was expecting. But A didn't appear in the entry espaces list in C. I realized (just a few minutes ago) that A didn't consume C. So what I had to do was to create a 'fake' reference from A to C (some action for example). So, now A consumes C and appears in the list, and I can debug now. Not the perfect solution, but it works.
 Joao -

If you are using an up-to-date version of Studio, that *usually* means that B and A need to be published to get the latest versions of C.

J.Ja
Justin James wrote:
João Melo wrote:
Hello people,

How about debugging in a 3+ levels of espaces?

This is the scenario:
1. Front-end espace A has a Screen Action that triggers an Action in the espace B
2. The action in B triggers an Action in the espace C
3. It's impossible to debub the Action in C.

Had someone experienced this?
 Joao -

In C, set "entry espace" to A and turn on debugger, that works for me.

?J.Ja
 I never realized that. Awesome! 
 

J.Ja,   We have had some difficulty setting up the debugging that is similar to Joao question. If done correctly where A references B and B references C, should I be able to debug C without creating the "fake reference A->C?  I understadn the idea of setting the entry espace, but, I do not recall seeing A when starting the debugger in C.
David Blezard wrote:

J.Ja,   We have had some difficulty setting up the debugging that is similar to Joao question. If done correctly where A references B and B references C, should I be able to debug C without creating the "fake reference A->C?  I understadn the idea of setting the entry espace, but, I do not recall seeing A when starting the debugger in C.
 David -

Make sure that both B and A have been published AFTER C, and make sure that B gets published BEFORE A.

This is all part of the overall architecture of how the DLLs (for .NET) and JARs/WARs (on Java) get built.

Under the hood, when you publish an eSpace it collects the most recent DLLs or JARs from the referenced eSpaces and Extensions and uses them in the publish. So on a .NET server, when you publish A it will make symbolic links in A's deployment directory to the DLLs compiled from B and C. On Java, I think it copies the JAR files for B and C and puts them into A's WAR.

When you turn on the debugger, the "entry eSpace" basically says "debug the code in THIS deployment directory which is the one that will service the request."

End result is that your publish order must be C, B, A, then set the entry eSpace to A, for debugging to work.

J.Ja
 

Thanks. That makes sense. I'll give that a try. We have .NET instalation.
Justin James wrote:
João Melo wrote:
Thanks again Justin. That is what I was expecting. But A didn't appear in the entry espaces list in C. I realized (just a few minutes ago) that A didn't consume C. So what I had to do was to create a 'fake' reference from A to C (some action for example). So, now A consumes C and appears in the list, and I can debug now. Not the perfect solution, but it works.
 Joao -

If you are using an up-to-date version of Studio, that *usually* means that B and A need to be published to get the latest versions of C.

J.Ja
 
 Justin, at v9.0.60 it's not enough to have the references refreshed. You really need to 'fake' a reference between A and C.

I'm gonna check at 9.1 later.

Thanks.

João Melo wrote:
Justin James wrote:
João Melo wrote:
Thanks again Justin. That is what I was expecting. But A didn't appear in the entry espaces list in C. I realized (just a few minutes ago) that A didn't consume C. So what I had to do was to create a 'fake' reference from A to C (some action for example). So, now A consumes C and appears in the list, and I can debug now. Not the perfect solution, but it works.
 Joao -

If you are using an up-to-date version of Studio, that *usually* means that B and A need to be published to get the latest versions of C.

J.Ja
 
 Justin, at v9.0.60 it's not enough to have the references refreshed. You really need to 'fake' a reference between A and C.

I'm gonna check at 9.1 later.

Thanks.
 
 
 Joao -

Got it, good to know!

J.Ja
 Justin, at v9.0.60 it's not enough to have the references refreshed. You really need to 'fake' a reference between A and C.
I'm pretty sure this is not the case on the .NET version. I don't know for Java - which Platform are you using?
Java
Ok, thanks, rules for Java are different then.