commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <>
Subject Re: [scxml] SCXMLExecutor#getSCInstance ... any chance to make it public?
Date Thu, 20 Apr 2006 06:44:08 GMT
On 4/19/06, Nestor Urquiza <> wrote:
> Hello,
> I am planning to store just the SCXMLExecutor in a per
> session basis.

Sounds good.

> Then of course I need to have access
> from my "bridge" to SCInstance#getRootContext to
> obtain the context needed to set variables from my
> specific-code.
> The problem is right now the
> SCXMLExecutor#getSCInstance has package access
> Can we make it public? Or there is a better way to
> accomplish what I am trying to do???
> Thanks a lot!

No, its best not made public. The SCInstance is really getting into
the internals of the SCXML engine. It holds the references needed for
a particular execution, the contexts and histories for that execution,
and shouldn't be exposed to the casual user. However, for "advanced"
usage, accessing these internals are often necessary, so for users who
wish to author:

 * Custom actions
 * Custom SCXML semantics

the SCInstance is made available via method signatures in the public
contract (see SCXMLSemantics interface, and custom actions page in
user guide).

The root context for an SCXML document is its link to the environment
this document is being used in (i.e. the environment variables). It
often merely wraps another "context" (set of variables). Couple of

 * The RootContext in the o.a.c.s.env.jsp package wraps a JspContext,
i.e. any variables defined in the JSP are available within the SCXML
 * The SessionContext in the o.a.c.s.env.faces package wraps a
"session map", i.e. any attributes defined in the associated session
are available within the SCXML document

The nightlies by no means provide a complete list of such Context
impls, and you may have to write one if needed (but the impls are
usually trivial, since they merely delegate to some backing
environment context).

So, often setting variables in the root context does *not* involve this:

// assuming the getter method was available
exec.getRootContext().set("foo", fooValue)

rather something like so:

<c:set var="foo" value="foovalue" /> <%-- in host JSP --%>

or so:

session.setAttribute("foo", foovalue); // defining session attribute

and that gets picked up due to the delegating root context.

Also, as Faish points out, the pseudo often looks like:

Context rootCtx = // new suitable context type
SCXMLExecutor exec = // new executor
exec.setStateMachine(// parsed, procedurally constructed SCXML object);

We probably could have a symmetric SCXMLExecutor#getRootContext() to
match the setter, but the absence of a getter actually encourages the
preferred latter usages (please open a request in bugzilla [1] for the
getter if you have an example of why you'd rather set variables using
the former usage).



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message