JBossDeveloper

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.

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

Looks good to me!

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

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

Security - SwitchYard - Project Documentation Editor

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