[dward]

Gotcha.  Well these are the impl types I have that detail formatter assigned to:

It's too bad we can't assign it per interfaces vs. hard implementations.

[rcernich]

You know what would be cool...having an eclipse preferences file containing useful detail formatters that users could import into their workspaces.  Just an idea.

[rcernich]

I've updated the service breakpoint to be triggered based on the exchange phase (in/out/fault) and the aspect being handled (e.g. transaction, security, target invocation).  For example, if the trigger phase is set to IN and the TRANSACTION aspect is enabled, the application will break when the transaction handler is invoked during IN processing, but not during OUT or FAULT.  By default consumer breakpoints will be configured for IN/OUT + ENTRY/RETURN/FAULT; provider breakpoints will be configured for IN/OUT + ENTRY/TARGET_INVOCATION/RETURN/FAULT (i.e. you get an extra break just before the provider is actually invoked).

Here's a screenshot that might help.

Let me know what you think.

[kcbabo]

Hey Rob,

This is looking great.  I've already shared a portion of this feedback with you directly, but I'll repeat it here so that other people watching the thread can participate.

First off, I think it's very important to split features of the debugger into two different groups/perspectives:

• Users : this perspective focuses on application-level concepts and avoids exposing SY internals.
• Developers : this is a more advanced perspective which allows breakpoint visibility and configuration at system-level, potentially exposing SY internal details to some extent.

Here are the elements that I think are critical for the User perspective:

• Ability to set breakpoints on services and references in the model.  The breakpoint should be visible in the model. [complete]
• Ability to debug in the test runtime and a remote runtime. [complete]
• Ability to set a breakpoint "on fault", which is triggered at the point a fault is generated in the application.  This is useful when you want to target the source of an application error immediately.
• Provide a content view which is distinct from the variable debugger view, which can be quite busy.
• Provide a context view which (possibly tabular) which shows the name/value/scope of context properties.
• Collect commonly used information in a view distinct from the variable view (service name, operation, etc.).
• All three of the above ideally are combined in a distinct view from the variable debugger view.
• Allow read/write on message content and context properties.
• When a breakpoint is triggered, bring focus to the breakpoint in the application view instead of the line of Java code which triggers the breakpoint.  One example would be changing the debugger glasses from black to red, although this might not be visible enough for some.

Here are the elements which I think are unique to the Developer perspective:

• Ability to view SY runtime code behind the breakpoint.
• Ability to set breakpoints at processors (this includes the Security, Policy, Transaction, etc. "triggers" in your screen shot).

I think both perspectives will be of great use to users and developers on the project.  I do think we should focus on the User perspective first, though.  Otherwise, we risk drowning the debugger interface with low-level details which will be a bit overwhelming and confusing for people without knowledge of the internals.

cheers,

keith

[rcernich]

I've added a custom view (currently named SwitchYard Context, but I might change that to SwitchYard Variables?). reworked some of the structure (e.g. Interaction Details) and added some new elements (e.g. Transaction Details and Security Context).  Attached is a screenshot.

[rcernich]

I also have "Change Value..." working for select variables, but the changes made aren't yet reflected in the view.

[kcbabo]

Looks good to me!

[dward]

Can you try with one of the security quickstarts so I can see what the security context would look like in this?

[rcernich]

Hey David,

Screenshot with Security Context.  This was obtained debugging the demos/policy-security-basic quickstart.

[dward]

Thanks Rob. Just be careful 'cause if configured so, the SecurityContext could actually be wrapped in a SealedObject:

Security - SwitchYard - Project Documentation Editor

[rcernich]

The debugger functionality is now available in the latest integration build of the 2.0 tools:  http://download.jboss.org/jbosstools/updates/integration/kepler/integration-stack/switchyard/2.0.0/

[jbride]

Very nice Rob!

Just gave this a whirl .... looks great!

I experimented by placing breakpoints in various locations of various quickstarts deployed to a remote FSW-6.0.0.GA-redhat-4   runtime;  and i had no problems.

thank you!  jeff