[jira] Commented: (DIGESTER-115) Digester depends on BeanUtils copies of Collections classes

[Rahul Akolkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIGESTER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513979
 ] 

Rahul Akolkar commented on DIGESTER-115:


But a "tighter" ArrayStack wouldn't work (given fix version is 1.8.1). In the 
longer run, I agree, we should wean [digester] off of the [collections] version 
of ArrayStack (doing what you suggest or just using java.util.Stack or some 
such so we will have one less class to maintain).


> Digester depends on BeanUtils copies of Collections classes
> ---
>
> Key: DIGESTER-115
> URL: https://issues.apache.org/jira/browse/DIGESTER-115
> Project: Commons Digester
>  Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Niall Pemberton
> Fix For: 1.8.1
>
>
> This is related to issue# BEANUTILS-278
> Digester uses 3 classes (ArrayStack, Buffer and BufferUnderflowException) 
> from commons BeanUtils which were copied from Commons Collections and 
> BEANUTILS-278 proposes removing them.
> ArrayStack.java
> Buffer.java
> BufferUnderflowException.java

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-49) SimpleSCXMLInvoker may miss transition to final state

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-49:
---

Fix Version/s: 0.7
 Assignee: Rahul Akolkar
Affects Version/s: (was: 0.7)
   0.6

Setting fix version to next release.


> SimpleSCXMLInvoker may miss transition to final state
> -
>
> Key: SCXML-49
> URL: https://issues.apache.org/jira/browse/SCXML-49
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Ingmar Kliche
>Assignee: Rahul Akolkar
> Fix For: 0.7
>
>
> The current implementation of SimpleSCXMLInvoker assumes that only external 
> events, handled by parentEvents(), may cause the child state machine to go 
> move a final state. But in case where the invoked state machine moves to a 
> final state directly (while executing the initial state, see example) the 
> parent never receives an "invoke.done". 
>  
> http://www.w3.org/2005/07/scxml version="1.0" 
> initialstate="state1">
>  
>
>
>   
>   
>  
>  
>  
> 
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.

[Rahul Akolkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508326
 ] 

Rahul Akolkar commented on SCXML-47:


Indeed, that should be out of the way. Please ping if it isn't. While I was at 
it, I've added the additional constructors that avoid the recurring parsing 
cost (by accepting the parsed SCXML instance instead of the URL to the 
document).


> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: additional-tests.tar.gz, state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might 
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
>   // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by 
> subclassing and for use by delegation.  The constructors are a little messy, 
> but in the end I have
> public class StateMachineSupport {
>   // use by subclassing
>   protected StateMachineSupport(...) {
>   }
>   // use by delegation
>   public StateMachineSupport(Object delegator, ...) {
>   }
>   // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
>   protected AbstractStateMachine(...) {
> super(...);
>   }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
>   ConcreteStateMachine() {
> super(..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
>   StateMachineSupport delegate;
>   DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java, 
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-48) Cannot create more than one subclass of AbstractStateMachine

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-48.


   Resolution: Fixed
Fix Version/s: 0.7

Thanks for the tests. They've been added to the test suite and a fix has been 
applied. Should be available in tomorrow's nightly (or immediately via trunk).


> Cannot create more than one subclass of AbstractStateMachine
> 
>
> Key: SCXML-48
> URL: https://issues.apache.org/jira/browse/SCXML-48
> Project: Commons SCXML
>  Issue Type: Bug
>Reporter: Michael Heuer
> Fix For: 0.7
>
> Attachments: abstract-state-machine-test-src.tar.gz
>
>
> Similar to the issue described in SCXML-47, the following test case will fail:
> public void testMoreThanOneScxmlDocument() throws Exception {
> URL fooScxmlDocument = getClass().getResource("foo.xml");
> URL barScxmlDocument = getClass().getResource("bar.xml");
> Foo foo = new Foo(fooScxmlDocument);
> Bar bar = new Bar(barScxmlDocument);
> assertTrue(fooCalled);
> // bar's initialstate "bar" never called, since bar's 
> AbstractStateMachine has
> // static reference to stateMachine for foo.xml
> assertTrue(barCalled);
> }
> private class Foo extends AbstractStateMachine {
> public Foo(final URL scxmlDocument) {
> super(scxmlDocument);
> }
> public void foo() {
> fooCalled = true;
> }
> }
> private class Bar extends AbstractStateMachine {
> public Bar(final URL scxmlDocument) {
> super(scxmlDocument);
> }
> public void bar() {
> barCalled = true;
> }
> }
> with simple SCXML files
> foo.xml:
> http://www.w3.org/2005/07/scxml"; version="1.0" 
> initialstate="foo">
>   
> 
> bar.xml:
> http://www.w3.org/2005/07/scxml"; version="1.0" 
> initialstate="bar">
>   
> 
> [junit] Running org.apache.commons.scxml.env.EnvTestSuite
> org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
> java.lang.NoSuchMethodException: 
> org.apache.commons.scxml.env.AbstractStateMachineTest$Bar.foo()
> at java.lang.Class.getDeclaredMethod(Class.java:1937)
> at 
> org.apache.commons.scxml.env.AbstractStateMachine.invoke(AbstractStateMachine.java:212)
> at 
> org.apache.commons.scxml.env.AbstractStateMachine$EntryListener.onEntry(AbstractStateMachine.java:269)
> Testsuite: org.apache.commons.scxml.env.EnvTestSuite
> Tests run: 21, Failures: 2, Errors: 0, Time elapsed: 0.391 sec
> Testcase: 
> testMoreThanOneScxmlDocument(org.apache.commons.scxml.env.AbstractStateMachineTest):
>   FAILED
> junit.framework.AssertionFailedError
> at 
> org.apache.commons.scxml.env.AbstractStateMachineTest.testMoreThanOneScxmlDocument(AbstractStateMachineTest.java:60)
> Testcase: testStopWatch(org.apache.commons.scxml.env.StopWatchTest):FAILED
> expected: but was:
> junit.framework.ComparisonFailure: expected: but was:
> at 
> org.apache.commons.scxml.env.StopWatchTest.testStopWatch(StopWatchTest.java:56)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.

[Rahul Akolkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506990
 ] 

Rahul Akolkar commented on SCXML-47:


Looks good, a few minutiae:

 * Perhaps it is better to have the name elaborate that the support is for 
authoring classes that model stateful entities (and the operations performed in 
those states). Do you think the name ClassStateMachineSupport makes more sense? 
It does to me, but I'm not very good with names.
 * The StateMachineSupport class (new name TBD) needs a ton of Javadoc at the 
class level so folks can get a hang of whats in there (thanks for the new 
method Javadocs). Some of your usage code snippets in the opening description 
of this issue would also help a lot as part of that Javadoc.
 * Code has unused imports (and some other warnings from my IDE about unused 
stuff that are probably bogus)
 * We should have only one AbstractStateMachine class (the current one can 
extend StateMachineSupport and we'll be done with that). I don't see what we 
can do about your constructors being a bit messy comment (I think we'll leave 
them the way you have them).

Do you want to make these changes? I can too, but I can't say when.


> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might 
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
>   // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by 
> subclassing and for use by delegation.  The constructors are a little messy, 
> but in the end I have
> public class StateMachineSupport {
>   // use by subclassing
>   protected StateMachineSupport(...) {
>   }
>   // use by delegation
>   public StateMachineSupport(Object delegator, ...) {
>   }
>   // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
>   protected AbstractStateMachine(...) {
> super(...);
>   }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
>   ConcreteStateMachine() {
> super(..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
>   StateMachineSupport delegate;
>   DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java, 
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.

[Rahul Akolkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505907
 ] 

Rahul Akolkar commented on SCXML-47:


Thanks, I can confirm that your CLA has been received (and recorded). I intend 
to take a look at the attachment and post any comments later in the week.


> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might 
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
>   // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by 
> subclassing and for use by delegation.  The constructors are a little messy, 
> but in the end I have
> public class StateMachineSupport {
>   // use by subclassing
>   protected StateMachineSupport(...) {
>   }
>   // use by delegation
>   public StateMachineSupport(Object delegator, ...) {
>   }
>   // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
>   protected AbstractStateMachine(...) {
> super(...);
>   }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
>   ConcreteStateMachine() {
> super(..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
>   StateMachineSupport delegate;
>   DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java, 
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-47) Provide a state machine support class to allow for delegation.

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-47:
---

Fix Version/s: 0.7
Affects Version/s: 0.6

Tentatively setting fix version to v0.7.


> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Priority: Minor
> Fix For: 0.7
>
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might 
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
>   // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by 
> subclassing and for use by delegation.  The constructors are a little messy, 
> but in the end I have
> public class StateMachineSupport {
>   // use by subclassing
>   protected StateMachineSupport(...) {
>   }
>   // use by delegation
>   public StateMachineSupport(Object delegator, ...) {
>   }
>   // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
>   protected AbstractStateMachine(...) {
> super(...);
>   }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
>   ConcreteStateMachine() {
> super(..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
>   StateMachineSupport delegate;
>   DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java, 
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-47) Provide a state machine support class to allow for delegation.

[Rahul Akolkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCXML-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505507
 ] 

Rahul Akolkar commented on SCXML-47:


Sounds useful; the AbstractStateMachine class hasn't been used much by me (it 
was put together for the stopwatch usecase) but I know others are using it. I 
believe many improvements are possible -- at some point, when we move to JDK 
1.5, we can take care of some of this with annotations instead which perhaps 
may be cleaner.

To begin, could you fill out an Individual Contributor License Agreement 
(ICLA)? That is here (the fax number is on the form itself, you can mail it in 
too if you want):

http://www.apache.org/licenses/icla.txt

Its a one-time thing, and is needed for non-trivial contributions, for code 
provenance and pedigree reasons. Please let us know if you have any questions 
about the ICLA. Ping this issue when you send it in (unless you choose not to), 
then we can track its receipt and dig into the details of this improvement. 
Thanks.


> Provide a state machine support class to allow for delegation.
> --
>
> Key: SCXML-47
> URL: https://issues.apache.org/jira/browse/SCXML-47
> Project: Commons SCXML
>  Issue Type: Improvement
>Reporter: Michael Heuer
>Priority: Minor
> Attachments: state-machine-support-src.tar.gz
>
>
> This is not completely thought out yet, but if folks like the idea I might 
> persue it further.
> I would like to use AbstractStateMachine but cannot extend from it:
> class B extends A /*, AbstractStateMachine */ {
>   // copy source from AbstractStateMachine here
> }
> I propose here a StateMachineSupport class that provides for use by 
> subclassing and for use by delegation.  The constructors are a little messy, 
> but in the end I have
> public class StateMachineSupport {
>   // use by subclassing
>   protected StateMachineSupport(...) {
>   }
>   // use by delegation
>   public StateMachineSupport(Object delegator, ...) {
>   }
>   // ... methods from AbstractStateMachine
> }
> public abstract class AbstractStateMachine extends StateMachineSupport {
>   protected AbstractStateMachine(...) {
> super(...);
>   }
> }
> // use by subclassing
> class ConcreteStateMachine extends AbstractStateMachine {
>   ConcreteStateMachine() {
> super(..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> // use by delegation
> class DelegatingStateMachine extends SomethingElse {
>   StateMachineSupport delegate;
>   DelegatingStateMachine() {
> delegate = new StateMachineSupport(this, ..."stopwatch.xml");
>   }
>   public void reset() { ... }
>   public void running() { ... }
>   public void paused() { ... }
>   public void stopped() { ... }
> }
> StateMachineSupport.java, AbstractStateMachine2.java, 
> StateMachineSupportTest.java, and AbstractStateMachine2Test.java attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-44) Interface consistency: State.getIsFinal and State.setIsFinal

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-44:
---

Fix Version/s: (was: 0.7)
   1.0

Suggested changes have been made. Original methods are now deprecated. Setting 
fix version to v1.0 when deprecations can be removed.


> Interface consistency: State.getIsFinal and State.setIsFinal
> 
>
> Key: SCXML-44
> URL: https://issues.apache.org/jira/browse/SCXML-44
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Jörg Weinmann
>Priority: Trivial
> Fix For: 1.0
>
>
> Getter and setter method for boolean isFinal is inconsistent to similiar 
> getter and setter methods in the class.
> I would have expected: State.isFinal() and State.setFinal().
> Compare to isDone(), isSimple(), isDone(), setDone().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-46) Provide a SCXMLListener abstract adapter class.

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-46.


Resolution: Fixed

Added, under the new name AbstractSCXMLListener. Thanks for the contribution.


> Provide a SCXMLListener abstract adapter class.
> ---
>
> Key: SCXML-46
> URL: https://issues.apache.org/jira/browse/SCXML-46
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Assignee: Rahul Akolkar
>Priority: Trivial
> Fix For: 0.7
>
> Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java
>
>
> Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java
> Might also want to add
> + suite.addTest(SCXMLAdapterTest.suite());
> to SCXMLTestSuite.java, line 54

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-41) Adding information to evaluation error messages

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-41.


Resolution: Fixed

The error message now contains the offending expression as well.


> Adding information to evaluation error messages
> ---
>
> Key: SCXML-41
> URL: https://issues.apache.org/jira/browse/SCXML-41
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Nestor Urquiza
>Assignee: Rahul Akolkar
> Fix For: 0.7
>
>
> Log trace like:
> EXPRESSION_ERROR (java.lang.NullPointerException)
> >
> We could output more than just
> he little message that comes from JEXL if we modify
>  JexlEvaluator#eval() to output the expr parameter when
> an Exception occurs.
> That way one can see easy the culprit line of JEXL/EL
> code.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-46) Provide a SCXMLListener abstract adapter class.

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-46:
---

Fix Version/s: 0.7
Affects Version/s: 0.6

> Provide a SCXMLListener abstract adapter class.
> ---
>
> Key: SCXML-46
> URL: https://issues.apache.org/jira/browse/SCXML-46
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Michael Heuer
>Assignee: Rahul Akolkar
>Priority: Trivial
> Fix For: 0.7
>
> Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java
>
>
> Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java
> Might also want to add
> + suite.addTest(SCXMLAdapterTest.suite());
> to SCXMLTestSuite.java, line 54

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-46) Provide a SCXMLListener abstract adapter class.

[Rahul Akolkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/SCXML-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505332
 ] 

Rahul Akolkar commented on SCXML-46:


Thanks for the addition and the tests. I think we should call the class 
AbstractSCXMLListener and put it in the oac.scxml.env package. OK?


> Provide a SCXMLListener abstract adapter class.
> ---
>
> Key: SCXML-46
> URL: https://issues.apache.org/jira/browse/SCXML-46
> Project: Commons SCXML
>  Issue Type: Improvement
>Reporter: Michael Heuer
>Assignee: Rahul Akolkar
>Priority: Trivial
> Attachments: SCXMLAdapter.java, SCXMLAdapterTest.java
>
>
> Attached are new files SCMLAdapter.java and SCXMLAdapterTest.java
> Might also want to add
> + suite.addTest(SCXMLAdapterTest.suite());
> to SCXMLTestSuite.java, line 54

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-45) Payload of events sent to current scxml session using tag not injected into engine

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-45.


   Resolution: Fixed
Fix Version/s: 0.7

Copying the commit message from r542582:

This has been implemented (with a test case), however note the following caveat 
--

The spec doesn't clarify how multiple  elements that create derived 
events should be handled, so for example:


 
 


I think they should be processed together (this makes sense to leverage 
parallel regions for example), and due to that '_eventdata' becomes ambiguous 
in this scenario. The Commons SCXML implementation introduces an implicit 
variable '_eventdatamap' for such scenarios wherein the event datas are stored 
keyed by event name.

So, the two  events above could be processed by two regions like so:



 





 

 





 

 



To summarize, the _eventdatamap variable needs to be used in association with 
"derived" (such as  being discussed here) events. Also note that this 
behavior may change if there is clarity in the specification at some point.


> Payload of events sent to current scxml session using  tag not injected 
> into engine
> -
>
> Key: SCXML-45
> URL: https://issues.apache.org/jira/browse/SCXML-45
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Ingmar Kliche
>Assignee: Rahul Akolkar
>Priority: Minor
> Fix For: 0.7
>
>
> Events which are sent to the current scxml session using the  tag (i.e. 
> target = empty) may contain payload specified by the namelist attribute. This 
> payload is currently not fed back into engine when the event is created.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SANDBOX-185) [exec] setWatchDog method in DefaultExecutor has no affect

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SANDBOX-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SANDBOX-185.
---

Resolution: Fixed

Fixed by sgoeschl in r518598 [1].

[1] http://svn.apache.org/viewvc?view=rev&revision=518598


> [exec] setWatchDog method in DefaultExecutor has no affect
> --
>
> Key: SANDBOX-185
> URL: https://issues.apache.org/jira/browse/SANDBOX-185
> Project: Commons Sandbox
>  Issue Type: Bug
>  Components: Exec
> Environment: All Environments
>Reporter: Bindul Bhowmik
> Attachments: default-executor.patch
>
>
> The setWatchDog method in org.apache.commons.exec.DefaultExecutor.java does 
> not have any affect due to a case discrepancy. The method parameter for the 
> method is watchDog and the value that is assigned is watchdog (the same as 
> the class field).
> I have attached a patch for the same. If required I could add in a test case 
> for this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-44) Interface consistency: State.getIsFinal and State.setIsFinal

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-44:
---

Fix Version/s: 0.7

Lets aim to initiate a deprecate, replace and remove cycle starting v0.7.


> Interface consistency: State.getIsFinal and State.setIsFinal
> 
>
> Key: SCXML-44
> URL: https://issues.apache.org/jira/browse/SCXML-44
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Jörg Weinmann
>Priority: Trivial
> Fix For: 0.7
>
>
> Getter and setter method for boolean isFinal is inconsistent to similiar 
> getter and setter methods in the class.
> I would have expected: State.isFinal() and State.setFinal().
> Compare to isDone(), isSimple(), isDone(), setDone().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-43) SCXML parallelism

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-43.


Resolution: Invalid

Thanks for the details -- the SCXML document and state machine diagram. At 
first glance, it does not seem to be a problem with the Commons SCXML library. 
I will respond to your email on the user list (titled "SCXML error") in a few 
minutes.


> SCXML parallelism
> -
>
> Key: SCXML-43
> URL: https://issues.apache.org/jira/browse/SCXML-43
> Project: Commons SCXML
>  Issue Type: Task
> Environment: Windows
>Reporter: Premi John
>Priority: Critical
> Attachments: State_Machine_Diagram.bmp
>
>
> Hi there,
> We are trying to use SCXML for one of our use case where we have lots of 
> state transitions and event generated. I am having problem with having 
> multiple transitions defined within a state. I am attaching herewith the 
> state diagram and the SCXML that I have tried creating. Please give your 
> suggestions on where I am wrong in defining the SCXML. 
> Thanks
> John
> I am not able to attach the state diagram here and is there any forum where I 
> can send attachments.
> 
> 
> http://www.w3.org/2005/07/scxml";
>   xmlns:my="http://my.custom-actions.domain/CUSTOM"; version="1.0"
>   initialstate="testMain">
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>  
> cond="_eventdata.slotAvailable=true"
>   
> target="MSlotHeldState.aquireSlot" />
>  
> cond="_eventdata.slotavailable=true" 
>   
> target="MSlotLockedState.lockSlot"/>
>  
> cond="!_eventdata.slotAvailable"
>   
> target="MSlotQueuedState.queueSlot" />
>   
>   
>   
>   
>   
>   
>  
> target="MSlotCancelledState.freeSlot" />
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>  
> target="MSlotFreedState.releaseSlot" />
>   
>   
>   
>   
>   
>event="SlotReadyToBeHeldEvent" target="MSlotHeldState.aquireSlot" />
>   
>   
>   
>/>
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>  
> cond="_eventdata.aquireTaskId eq AQUIREtaskId"
>

[jira] Resolved: (SCXML-42) SCXML exception

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-42.


Resolution: Invalid

Please post questions to the user list first. Thanks.

> SCXML exception 
> 
>
> Key: SCXML-42
> URL: https://issues.apache.org/jira/browse/SCXML-42
> Project: Commons SCXML
>  Issue Type: Bug
> Environment: Windows
>Reporter: Premi John
>Priority: Blocker
>
> Hi there,
> While implementing the parallelism in SCXML we are encountering an exception 
> which I am attaching herewith. Is there any work around for this.
> 2007-04-12 11:52:44,922 INFO  [scxml.app.log] null: Slot Init State
> 2007-04-12 11:52:44,922 INFO  [scxml.app.log] null: Task Init State
> 2007-04-12 11:52:44,954 DEBUG [mdb] SQL Query - select 
> T_Schedule.SCH_ID,SCH_TYPE,SCH_KIND,SCH_USER,
> SCH_PRIORITY,SCH_NAME,SCH_CRON,SCH_DISABLE,SCH_RELID,SCH_PARENTID,SCH_AB
> ORT_INFO,SCH_TIME_POLICY,SCH_KIND,SCH_SUB_TYPE,SLOT_ID,RESID
> ,RESTYPE,SLOT_FROM_TIME , SLOT_TO_TIME,SLOT_CAPACITY , 
> SLOT_STATE,aTask.TASK_ID ,aTask.IRESID,aTask.LRESID ,aTask.TASK_OPKID , 
> aTask.TASK_OPKTYPE , aTask.TASK_JOBCMDSTR ,aTask.TASK_DELTA ,aTask.TASK_STATE 
> , bTask.TASK_ID ,bTask.IRESID,bTask.LRESID ,bTask.TASK_OPKID , 
> bTask.TASK_OPKTYPE , bTask.TASK_JOBCMDSTR ,bTask.TASK_DELTA 
> ,bTask.TASK_STATE,aTask.TASK_TIME,bTask.TASK_TIME from 
> T_schedule,T_SLOT,T_TASK aTask,T_TASK bTASK where T_Schedule.SCH_ID=?
> and T_Schedule.SCH_ID=T_SLOT.SCH_ID and T_SCHEDULE.SCH_ID=aTASK.SCH_ID and 
> T_SCHEDULE.SCH_ID=bTASK.SCH_ID and aTASK.TASK_ID != bTASK.TASK_ID group by 
> t_schedule.sch_id
> 2007-04-12 11:52:44,954 INFO  [STDOUT] MSlotTaskFSM :AQUIRE inside 
> MSlotTaskFSM of aTask:
> 2007-04-12 11:52:44,954 INFO  [STDOUT] MSlotTaskFSM :RELEASE inside 
> MSlotTaskFSM of bTask:
> 2007-04-12 11:52:44,954 INFO  [STDOUT] Inside ProcessEvent :Schedule Id is 
> :11:506
> 2007-04-12 11:52:45,109 WARN
> [org.apache.commons.scxml.env.SimpleErrorReporter] NON_DETERMINISTIC 
> (Multiple conflicting transitions enabled.):  [transition (event = 
> CreateATaskEvent, cond = _eventdata.slotAvailable=true, from = 
> /testMain/null/slotState/MSlotInitState, to = 
> /testMain/null/slotState/MSlotHeldState.aquireSlot), transition (event = 
> CreateATaskEvent, cond = !_eventdata.slotAvailable, from = 
> /testMain/null/slotState/MSlotInitState, to = 
> /testMain/null/slotState/MSlotQueuedState.queueSlot), transition (event = 
> CreateATaskEvent, cond = _eventdata.slotavailable=true, from = 
> /testMain/null/slotState/MSlotInitState, to = 
> /testMain/null/slotState/MSlotLockedState.lockSlot)]
> 2007-04-12 11:52:45,109 WARN
> [org.apache.commons.scxml.env.SimpleErrorReporter] ILLEGAL_CONFIG (Multiple 
> OR states active for state slotState):
> /testMain/null/slotState :
> [/testMain/null/slotState/MSlotHeldState.aquireSlot,
> /testMain/null/slotState/MSlotQueuedState.queueSlot,
> /testMain/null/slotState/MSlotLockedState.lockSlot]
> 2007-04-12 11:52:45,109 ERROR [com.hp.m.msched.core.MSlotTaskFSM]
> Illegal state machine configuration!
> org.apache.commons.scxml.model.ModelException: Illegal state machine 
> configuration!
>   at
> org.apache.commons.scxml.semantics.SCXMLSemanticsImpl.followTransitions(
> SCXMLSemanticsImpl.java:695)
>   at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvents(SCXMLExecutor.java:
> 127)
>   at
> org.apache.commons.scxml.SCXMLExecutor.triggerEvent(SCXMLExecutor.java:1
> 60)
>   at
> com.hp.m.msched.core.MSlotTaskFSM.fireEvent(MSlotTaskFSM.java:151)
>   at
> com.hp.m.msched.core.MScheduleController.processEvent(MScheduleControlle
> r.java:71)
>   at
> com.hp.m.msched.core.MScheduleResourceController.processMessage(MSchedul
> eResourceController.java:171)
>   at
> com.hp.m.msched.mmsg.MSchedSCNMessageHandler.processMessage(MSchedSCNMes
> sageHandler.java:38)
>   at com.hp.m.mmsg.jms.mdb.MDB.onMessage(MDB.java:49)
>   at com.hp.m.mmsg.jms.mdb.MSchedMDB.onMessage(MSchedMDB.java:9)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:324)
>   at
> org.jboss.invocation.Invocation.performCall(Invocation.java:359)
>   at
> org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(Message
> DrivenContainer.java:495)
>   at
> org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(
> CachedConnectionInterceptor.java:158)
>   at
> org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInt
> erceptor.java:63)
>   at
> org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterce
> ptor.java:

[jira] Updated: (SCXML-39) Deprecations associated with Feb '07 WD changes

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-39:
---

Description: 
Placeholder issue for listing all deprecations introduced by changes in the Feb 
'07 WD.

1) State#getTransitions():
 * In favor of getTransitionsList() which helps better retain document order. 
 * Deprecated in r515834 while at 0.7-SNAPSHOT.

2...n) TODO: complete this


  was:
In favor of getTransitionsList() which helps better retain document order.

Deprecated in r515834 while at 0.7-SNAPSHOT. Remove before v1.0.


Summary: Deprecations associated with Feb '07 WD changes  (was: 
Deprecate State#getTransitions())

> Deprecations associated with Feb '07 WD changes
> ---
>
> Key: SCXML-39
> URL: https://issues.apache.org/jira/browse/SCXML-39
> Project: Commons SCXML
>  Issue Type: Task
>Affects Versions: 0.6
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 1.0
>
>
> Placeholder issue for listing all deprecations introduced by changes in the 
> Feb '07 WD.
> 1) State#getTransitions():
>  * In favor of getTransitionsList() which helps better retain document order. 
>  * Deprecated in r515834 while at 0.7-SNAPSHOT.
> 2...n) TODO: complete this

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-40) provide a mechanism to add a session Id to current var, assign traces using a new Executor member.

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-40:
---

Fix Version/s: 0.7
 Assignee: Rahul Akolkar
Affects Version/s: 0.6

> provide a mechanism to add a session Id to current var, assign traces using a 
> new Executor member.
> --
>
> Key: SCXML-40
> URL: https://issues.apache.org/jira/browse/SCXML-40
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Nestor Urquiza
> Assigned To: Rahul Akolkar
> Fix For: 0.7
>
>
> In a concurrent environment like a web application it
> is of a tremendous important to get the Session Id
> together with any log trace.
> Given the fact an executor
> defines uniquely a State Machine status at any time it
> is the executor the one that ideally should carry an
> identifier.
> I would allow that identifier to be accessible with
> getter/setter methods. That way one can decide to set
> the exec#id with the session Id and later that member
> could be used to be output as part of the current var,
> assign traces.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-41) Adding information to evaluation error messages

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-41:
---

Fix Version/s: 0.7
 Assignee: Rahul Akolkar
Affects Version/s: 0.6

> Adding information to evaluation error messages
> ---
>
> Key: SCXML-41
> URL: https://issues.apache.org/jira/browse/SCXML-41
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.6
>Reporter: Nestor Urquiza
> Assigned To: Rahul Akolkar
> Fix For: 0.7
>
>
> Log trace like:
> EXPRESSION_ERROR (java.lang.NullPointerException)
> >
> We could output more than just
> he little message that comes from JEXL if we modify
>  JexlEvaluator#eval() to output the expr parameter when
> an Exception occurs.
> That way one can see easy the culprit line of JEXL/EL
> code.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-39) Deprecate State#getTransitions()

[Rahul Akolkar (JIRA)]

Deprecate State#getTransitions()


 Key: SCXML-39
 URL: https://issues.apache.org/jira/browse/SCXML-39
 Project: Commons SCXML
  Issue Type: Task
Affects Versions: 0.6
Reporter: Rahul Akolkar
 Assigned To: Rahul Akolkar
 Fix For: 1.0


In favor of getTransitionsList() which helps better retain document order.

Deprecated in r515834 while at 0.7-SNAPSHOT. Remove before v1.0.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-38) spec and semantics of initialstate attribute not clear for external state

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar resolved SCXML-38.


Resolution: Won't Fix

Two components to this as the title suggests:

a) Any inconsistencies found in the spec document - While we don't deal with 
those here, it'll be great if you can report them to the W3C WG.

b) The test case you have posted -- I suspect the majority of problems you are 
running into with this test case have to do with the fact that once the 
external SCXML document is pulled in, the state IDs are no longer unique 
("start" is present in both). Ofcourse, there are scenarios where you may want 
to pull in the same document couple of times in the state machine whereby you 
have to employ some state templating techniques (the src attribute can point to 
a URI generating dynamic content). I seem to remember someone writing up a wiki 
page on the Commons SCXML wiki for this. Please check it out or look into the 
mailing list archives for discussions on this. Also, please feel free to ask on 
the user list.


> spec and semantics of initialstate attribute not clear for external state
> -
>
> Key: SCXML-38
> URL: https://issues.apache.org/jira/browse/SCXML-38
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.6
> Environment: Win XP, Java 5, Eclipse 3.2, JUnit 4
>Reporter: Wolfgang Frech
>Priority: Minor
>
> The WD-SCXML is not fully consistent if the initialstate attribute is 
> required for an external state, that is a state that has a src attribute 
> pointing to a file containing its content.
> The attribute details (WD 3.1.1) define the initialstate attribute as 
> required, without any exception for external states.
> The example Test2Sub1.scxml (WD F.1) does not have a initialstate attribute.
> If this is only a minor omission in the example, the real issue is: how does 
> an initialstate attribute affect the behavior of the state chart?
> So far this would be only an issue with the WD.
> The commons SCXML implementation decided to treat the initialstate attribute 
> as required.
> Demonstration code follows.
> The issue with the commons implementation is:
> It is not clear which (state) id can be given in the initialstate attribute 
> of an external state SCXML file and what this means.
> The id of the external state itself is not accepted. See second demonstration 
> code.
> Demo - initialstate required:
> 
>   @Test
>   public void externalStateWithoutInitialstate() throws 
> FileNotFoundException,
>   IOException, SAXException, ModelException {
>   final URL definition = getClass().getClassLoader().getResource(
>   "externalStateWithoutInitialstate-main.scxml");
>   try {
>   SCXMLDigester.digest(definition, new 
> SimpleErrorHandler());
>   fail();
>   } catch (ModelException e) {
>   assertEquals(
>   "Initial state null or not a descendant 
> of state with ID \"start\"",
>   e.getMessage());
>   }
>   }
> 
> main scxml
> 
> 
>xmlns="http://www.w3.org/2005/07/scxml";
>   version="1.0"
>   initialstate="start">
>   
> 
> 
> included scxml 
> note: no initalstate
> 
> 
>xmlns="http://www.w3.org/2005/07/scxml";
>   version="1.0">
>   
> 
> Demo - with initialstate pointing to external state
> -
>   @Test
>   public void externalStateWithInitialstate() throws 
> FileNotFoundException,
>   IOException, SAXException, ModelException {
>   final URL definition = getClass().getClassLoader().getResource(
>   "externalStateWithInitialstate-main.scxml");
>   try {
>   SCXMLDigester.digest(definition, new 
> SimpleErrorHandler());
>   fail();
>   } catch (ModelException e) {
>   assertEquals(
>   "Initial state null or not a descendant 
> of state with ID \"start\"",
>   e.getMessage());
>   }
>   }
> -
> main scxml
> -
> 
>xmlns="http://www.w3.org/2005/07/scxml";
>   version="1.0"
>   initialstate="start">
>   
> 
> 
> included scxml
> note: with initialstate
> 
> 
>xmlns="http://www.w3.org/2005/07/scxml";
>   version="1.0"
>   initialstate="start">
>   
> 
>   
> 
>   
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-m

[jira] Updated: (SCXML-37) state with src attribute must not have children

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-37:
---

Fix Version/s: 1.0

That correct, though a couple of comments:

1) Its hard to express this constraint via a DTD (or even a schema).

2) I believe specific elements should be allowed for better reuse and 
expressivity (,  and s come quickly to mind). But 
that is something I need to bring up with the Working Group.

Setting for a fix version of 1.0.


> state with src attribute must not have children
> ---
>
> Key: SCXML-37
> URL: https://issues.apache.org/jira/browse/SCXML-37
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.6
> Environment: Win XP, JDK 1.5  Eclipse 3.2, JUnit 4, details on request
>Reporter: Wolfgang Frech
>Priority: Minor
> Fix For: 1.0
>
>
> The Digester accepts an SCXML model with a state that has both a src 
> attribute (and its contents defined in an external file), and an additional 
> onentry child.
> According to the WD-SCXML section 3.2.1, "If [the src attribute] is present, 
> no children are allowed."
> Test case to demonstrate the actual behavior follows
> JUnit test method
> 
>   @Test
>   public void externalStateWithChildren() throws FileNotFoundException,
>   IOException, SAXException, ModelException {
>   final URL definition = getClass().getClassLoader().getResource(
>   "externalStateWithChild-main.scxml");
>   SCXML scxml = SCXMLDigester.digest(definition, new 
> SimpleErrorHandler());
>   // expected/correct: digesting should throw exception
>   // according to WD-SCXML 3.2.1 "If [the src attribute] is 
> present, no
>   // children are allowed."
>   // actual/incorrect
>   assertNotNull(scxml);
>   }
> 
> main scxml
> 
> 
>xmlns="http://www.w3.org/2005/07/scxml";
>   version="1.0"
>   initialstate="external">
>id="external"
> src="externalStateWithChild-external.scxml">
> 
>expr="'This onentry child should not be accepted according to 
> WD-SCXML 3.2.1 Description'" />
> 
>   
> 
> external scxml
> 
> ?xml version="1.0"?>
>xmlns="http://www.w3.org/2005/07/scxml";
>   version="1.0"
>   initialstate="start">
>
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (LANG-320) LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions

[Rahul Akolkar (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471837
 ] 

Rahul Akolkar commented on LANG-320:


Might want to consider guarding such tests where expected results are 
vendor-specific (potentially LANG-318 as well, though haven't looked at that 
closely) based on the vendor information. [lang] itself provides 
SystemUtils.JAVA_VENDOR etc. to make the information trivially accessible.


> LocaleUtilsTest fails with IBM JDK 1.5.0 because of false assuptions
> 
>
> Key: LANG-320
> URL: https://issues.apache.org/jira/browse/LANG-320
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Joerg Schaible
>
> LocaleUtilsTest.testLanguagesByCountry makes the assumption, that within the 
> JDK there is only one language defined for GB: en. This is not true for the 
> IBM JDK 1.5.0 that also knows about cy_GB i.e. Welsh.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-36) Invoke cancel method called despite special done event triggered

[Rahul Akolkar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SCXML-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rahul Akolkar updated SCXML-36:
---

Fix Version/s: 0.7

Lets see if the next draft sheds some light on this, setting fix version to 
next release (0.7) for now.


> Invoke cancel method called despite special done event triggered
> 
>
> Key: SCXML-36
> URL: https://issues.apache.org/jira/browse/SCXML-36
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.6
>Reporter: Elam Birnbaum
>Priority: Minor
> Fix For: 0.7
>
>
> Creating an invoker class by implementing the Invoker interface requires you 
> to implement the invoke, parentEvents, and cancel methods. The invoke method 
> is expected to perform the invoker's task and the user must trigger a special 
> done event within it to signify the invoker is complete. The cancel method is 
> expected to be called from the outside to cancel the invoke process, 
> especially if the invoke process were being handled in a separate thread and 
> the thread has become a zombie. It would be called if an event were triggered 
> while the state engine was within the state containing the invoke, since that 
> event would be expected to interrupt the invoke. The issue, however, is that 
> the cancel method is called even if the triggered event is the special done 
> event signifying the end of the invoke, causing the cancel method to always 
> be called regardless of whether the invoke was indeed a zombie or not.
> The system should work so that the special done event triggered while in an 
> invoke should not cause the cancel method on the invoker class to be called. 
> An investigation should take place to determine if this should apply to any 
> event triggered by the invoker itself (though I am not sure how you are able 
> to make that determination if the invoker spawns off separate threads that 
> could trigger the events) should cause the cancel method to be called.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JEXL-31) Make it possible to run the jar target without running the test target

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-31?page=all ]

Rahul Akolkar resolved JEXL-31.
---

Resolution: Won't Fix

This is a small change, but the file is generated based on m1's idea of the 
build lifecycle. I do not wish to maintain it by hand, so I am resolving this 
as Won't Fix. However, if someone else wants to volunteer to change this as 
proposed (and implied therein, also volunteer to maintain the hand-edited 
artifact each time the pom changes in the future), this could be re-opened.


> Make it possible to run the jar target without running the test target
> --
>
> Key: JEXL-31
> URL: http://issues.apache.org/jira/browse/JEXL-31
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.0, 1.0 Beta 1, 1.1, 2.0, 1.1.1
> Environment: Gentoo Linux
>Reporter: Petteri Räty
>Priority: Minor
> Attachments: test-target.patch
>
>
> Now it is not possible to run the jar target without running the tests. For 
> Gentoo ebuilds it must be possible to just create the jar and optionally run 
> the tests if the user wants to run them so I created a patch to only run the 
> test target under the dist target instead of the jar target. This is also the 
> way this is most commonly done in java projects. Attached patch follows.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-16) The 'target' of a cannot be a data element name

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-16?page=all ]

Rahul Akolkar resolved SCXML-16.


Fix Version/s: 0.6
   (was: 1.0)
   Resolution: Fixed

Thanks for the patch, I've clarified that target and targettype should be 
expressions. Fixed in trunk.



> The 'target' of a  cannot be a data element name
> --
>
> Key: SCXML-16
> URL: http://issues.apache.org/jira/browse/SCXML-16
> Project: Commons SCXML
>  Issue Type: Bug
> Environment: Windows, JDK 1.4.2
>Reporter: Sitthichai Rernglertpricha
> Assigned To: Rahul Akolkar
>Priority: Minor
> Fix For: 0.6
>
> Attachments: patch-send.txt
>
>
> Based on the SCXML specification, the 'target' attribute of a  element 
> can be "expression returning a unique identifier of the event target".
> The specification also shows an example that reads the target from a data 
> element within .
> The current SCXML runtime treats target as a literal string and does not 
> "evaluate" it.
> The attached patch file shows a way to "evalulate" the target before calling 
> the EventDispatcher#send method, and support specifying the target by a data 
> element. Enclosing target within single-quote will prevent evaluation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-35) Deprecate two argument Data() methods in oacs.Builtin

[Rahul Akolkar (JIRA)]

Deprecate two argument Data() methods in oacs.Builtin
-

 Key: SCXML-35
 URL: http://issues.apache.org/jira/browse/SCXML-35
 Project: Commons SCXML
  Issue Type: Task
Affects Versions: 0.5
Reporter: Rahul Akolkar
 Assigned To: Rahul Akolkar
 Fix For: 1.0


In favor of the 3 argument namespace-aware ones. Deprecated in code for v0.6, 
remove in v1.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-34) Deprecate oacsm.Invoke#getParams()

[Rahul Akolkar (JIRA)]

Deprecate oacsm.Invoke#getParams()
--

 Key: SCXML-34
 URL: http://issues.apache.org/jira/browse/SCXML-34
 Project: Commons SCXML
  Issue Type: Task
Affects Versions: 0.5
Reporter: Rahul Akolkar
 Assigned To: Rahul Akolkar
 Fix For: 1.0


Invoke needs to hold actual Param children, not just a name -> expr map. 
Changed in SVN. Remove method in v1.0.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-22) The engine must report error/warning when invalid events are triggered

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-22?page=all ]

Rahul Akolkar updated SCXML-22:
---

Fix Version/s: 1.0
   (was: 0.6)

> The engine must report error/warning when invalid events are triggered
> --
>
> Key: SCXML-22
> URL: http://issues.apache.org/jira/browse/SCXML-22
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
> Environment: Win XP Professional, jdk 1.4.02
>Reporter: Raj Rao
> Fix For: 1.0
>
>
> The semantics must report an error/warning/notification when an invalid event 
> is triggered, instead of silently discarding it. An invalid event is one that 
> is not specified for the current state.
> Here's an excerpt of a converstaion, where the suggested workaround was not 
> applicable. This requirement is crucial for me.
> --
> Raj
> --
> > Hello,
> >
> > I tried sending an invalid event to the state machine
> > and didn't see any error being reported. By invalid I
> > mean this event was not expected in the current state.
> >
> > Does the SCXMLSemanticsImpl report an error (via the
> > the ErrorReporter) when such an event is silently
> > discarded?
> >
> 
> No, because the semantics treat it as simply an inconsequential
> trigger (causing no change to the state machine), rather than an
> error.
> One of the ways you could track this is to register a SCXMLListener on
> the executor and track onTransition() callbacks (if you get none, the
> trigger is "invalid" -- per your definition above).
> -Rahul

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-16) The 'target' of a cannot be a data element name

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-16?page=all ]

Rahul Akolkar updated SCXML-16:
---

Fix Version/s: 1.0
   (was: 0.6)

Probably needs spec clarification, I'll look into that.



> The 'target' of a  cannot be a data element name
> --
>
> Key: SCXML-16
> URL: http://issues.apache.org/jira/browse/SCXML-16
> Project: Commons SCXML
>  Issue Type: Bug
> Environment: Windows, JDK 1.4.2
>Reporter: Sitthichai Rernglertpricha
> Assigned To: Rahul Akolkar
>Priority: Minor
> Fix For: 1.0
>
> Attachments: patch-send.txt
>
>
> Based on the SCXML specification, the 'target' attribute of a  element 
> can be "expression returning a unique identifier of the event target".
> The specification also shows an example that reads the target from a data 
> element within .
> The current SCXML runtime treats target as a literal string and does not 
> "evaluate" it.
> The attached patch file shows a way to "evalulate" the target before calling 
> the EventDispatcher#send method, and support specifying the target by a data 
> element. Enclosing target within single-quote will prevent evaluation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-33) Namespaced XPath support for

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-33?page=all ]

Rahul Akolkar resolved SCXML-33.


Resolution: Fixed

> Namespaced XPath support for 
> ---
>
> Key: SCXML-33
> URL: http://issues.apache.org/jira/browse/SCXML-33
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> Currently,  content undefines the default namespace so the (prefixless) 
> deferred XPath expression evaluation can work. With Digester 1.8 released, it 
> should be possible to retain prefix information from the document such that 
> prefixes can be resolved at expression evaluation time.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-24) Add (and remove) CustomDigester

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-24?page=all ]

Rahul Akolkar resolved SCXML-24.


Resolution: Fixed

Custom digester removed.


> Add (and remove) CustomDigester
> ---
>
> Key: SCXML-24
> URL: http://issues.apache.org/jira/browse/SCXML-24
> Project: Commons SCXML
>  Issue Type: Task
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> Based on my allergic reaction to snapshot dependencies, lets introduce a 
> CustomDigester class (package scoped in the oacs.io package) which 
> essentially subclasses Digester and adds DIGESTER-107 functionality (which is 
> currently in digester trunk). Furthermore, remember to remove this class if 
> and when we see the next Digester release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-32) Upgrade core dependencies in time for v0.6

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-32?page=all ]

Rahul Akolkar resolved SCXML-32.


Resolution: Fixed

> Upgrade core dependencies in time for v0.6
> --
>
> Key: SCXML-32
> URL: http://issues.apache.org/jira/browse/SCXML-32
> Project: Commons SCXML
>  Issue Type: Task
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> Those that come to mind:
> Need Digester 1.8 for deferred evaluation of namespaced XPath expressions.
> JEXL 1.1 has many improvements so should be the recommended version (though 
> things will work with 1.0) .
> Similarly for Logging 1.1 (things will also work with 1.0.x).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-33) Namespaced XPath support for

[Rahul Akolkar (JIRA)]

Namespaced XPath support for 
---

 Key: SCXML-33
 URL: http://issues.apache.org/jira/browse/SCXML-33
 Project: Commons SCXML
  Issue Type: Improvement
Affects Versions: 0.5
Reporter: Rahul Akolkar
 Assigned To: Rahul Akolkar
 Fix For: 0.6


Currently,  content undefines the default namespace so the (prefixless) 
deferred XPath expression evaluation can work. With Digester 1.8 released, it 
should be possible to retain prefix information from the document such that 
prefixes can be resolved at expression evaluation time.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-32) Upgrade core dependencies in time for v0.6

[Rahul Akolkar (JIRA)]

Upgrade core dependencies in time for v0.6
--

 Key: SCXML-32
 URL: http://issues.apache.org/jira/browse/SCXML-32
 Project: Commons SCXML
  Issue Type: Task
Affects Versions: 0.5
Reporter: Rahul Akolkar
 Assigned To: Rahul Akolkar
 Fix For: 0.6


Those that come to mind:

Need Digester 1.8 for deferred evaluation of namespaced XPath expressions.

JEXL 1.1 has many improvements so should be the recommended version (though 
things will work with 1.0) .

Similarly for Logging 1.1 (things will also work with 1.0.x).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (DIGESTER-110) Create APIs that accept URL values directly, instead of only Strings to be converted to URLs

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/DIGESTER-110?page=comments#action_12452599 
] 

Rahul Akolkar commented on DIGESTER-110:


Looks good to me (didn't try applying since I'm on limited dev time this 
weekend). digester trunk is open for commits, please go ahead.


> Create APIs that accept URL values directly, instead of only Strings to be 
> converted to URLs
> 
>
> Key: DIGESTER-110
> URL: http://issues.apache.org/jira/browse/DIGESTER-110
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: 1.6 Final
>Reporter: Craig McClanahan
> Attachments: diffs.txt, URLTestCase.java
>
>
> Currently, Digester provides a number of convenience methods such as parse() 
> that access the XML content to be parsed in a variety of ways.  The most 
> commonly used ones are probably those that take the String form of a URL.
> In a web application environment, it is common for applications or frameworks 
> to call ServletContext.getResource() to acquire the URL of a web application 
> resource to be parsed.  With the current Digester implementation, this must 
> be converted to a String (using toString() or toExternalForm()), and then -- 
> internal to Digester -- converted back to a URL.  For this to work 
> successfully, there must be a lossless conversion of the URL returned by 
> ServletContext.getResource(), to a String, and then back to a URL.  While 
> this process succeeds on most popular servlet containers today, it is *not* 
> guaranteed to work ... it is entirely reasonable for a servlet container to 
> embed customized information in the URL implementation that is returned by 
> ServletContext.getResource(), and this information would be lost in the 
> conversions described above.
> To be safe, Digester should provide alternative public APIs that accept URLs 
> directly, in addition to the current APIs maintained for backwards 
> compatibility.  At a minimum, that would mean adding the following public 
> method signatures to Digester itself:
> * public Object parse(java.net.URL url)
> * public void register(java.lang.String publicId, java.net.URL entityURL)
> plus any other scenarios where strings are used as URLs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (DIGESTER-110) Create APIs that accept URL values directly, instead of only Strings to be converted to URLs

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/DIGESTER-110?page=comments#action_12452114 
] 

Rahul Akolkar commented on DIGESTER-110:


If you feel strongly that this should be in 1.8, feel free to jump in now and I 
will cut another RC when you're done with this. Thats no problem at all.


> Create APIs that accept URL values directly, instead of only Strings to be 
> converted to URLs
> 
>
> Key: DIGESTER-110
> URL: http://issues.apache.org/jira/browse/DIGESTER-110
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: 1.6 Final
>Reporter: Craig McClanahan
>
> Currently, Digester provides a number of convenience methods such as parse() 
> that access the XML content to be parsed in a variety of ways.  The most 
> commonly used ones are probably those that take the String form of a URL.
> In a web application environment, it is common for applications or frameworks 
> to call ServletContext.getResource() to acquire the URL of a web application 
> resource to be parsed.  With the current Digester implementation, this must 
> be converted to a String (using toString() or toExternalForm()), and then -- 
> internal to Digester -- converted back to a URL.  For this to work 
> successfully, there must be a lossless conversion of the URL returned by 
> ServletContext.getResource(), to a String, and then back to a URL.  While 
> this process succeeds on most popular servlet containers today, it is *not* 
> guaranteed to work ... it is entirely reasonable for a servlet container to 
> embed customized information in the URL implementation that is returned by 
> ServletContext.getResource(), and this information would be lost in the 
> conversions described above.
> To be safe, Digester should provide alternative public APIs that accept URLs 
> directly, in addition to the current APIs maintained for backwards 
> compatibility.  At a minimum, that would mean adding the following public 
> method signatures to Digester itself:
> * public Object parse(java.net.URL url)
> * public void register(java.lang.String publicId, java.net.URL entityURL)
> plus any other scenarios where strings are used as URLs.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-20) A Suggestion to enhance SCXMLExecutor and SCInstance class to support state persistence

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-20?page=all ]

Rahul Akolkar resolved SCXML-20.


Resolution: Fixed

Resolving, per previous comment.


> A Suggestion to enhance SCXMLExecutor and SCInstance class to support state 
> persistence
> ---
>
> Key: SCXML-20
> URL: http://issues.apache.org/jira/browse/SCXML-20
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
> Environment: Windows, JDK 1.4.2 and above
>Reporter: Sitthichai Rernglertpricha
> Fix For: 0.6
>
> Attachments: patches, scxmlservlet.war
>
>
> Currently, SCXMLExecutor and SCInstance does not implement Serializable. 
> Hence, under a clustered application server environment, they cannot be 
> persisted by the application server for session failover.
> Instead of changing SCXMLExecutor and SCInstance to implement Serializable, 
> an alternative is to leverage on the Memento design pattern so that 
> SCXMLExecutor and SCInstance class can persist their states via 2 new 
> saveState() and restoreState() methods. Both methods are passed a new 
> ExecutorState interface object. The SCXMLExecutor and SCInstance class will 
> save their states into the ExecutorState object when their saveState() 
> methods are called, and reload their states from the ExecutorState object 
> when their restoreState() methods are called. Different child implementation 
> of the ExecutorState interface will then handle the actual persistence to 
> appropriate channel, and decide what need to persist and what need not.
> For your consideration, I have attached patches to SCXMLExecutor and 
> SCInstance class with the 2 new saveState() and restoreState() methods, and 
> the new ExecutorState interface class.I have also attached a web application 
> (tested under Geronimo ) illustrating an implementation under Servlet 
> environment. Please refer to the readme.txt in the WAR file for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-31) Var and Assign to log the result of the evaluation

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-31?page=all ]

Rahul Akolkar resolved SCXML-31.


Resolution: Fixed

The patch is hard to use (since it has diffs of class files etc.), I have 
applied a variant, the log level is debug (instead of info):

 http://svn.apache.org/viewvc?view=rev&revision=478002



> Var and Assign to log the result of the evaluation
> --
>
> Key: SCXML-31
> URL: http://issues.apache.org/jira/browse/SCXML-31
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
> Environment: all
>Reporter: Nestor Urquiza
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
> Attachments: SCXML-31.patch
>
>
> Var#execute()
> ---
> Insert  after:
> String varStr = varObj==null?"null":varObj.toString();
> the following:
>  String msg = "Var." + name + "=" + varStr;
> if( appLog.isInfoEnabled() )
>appLog.info( msg );
> Assign#execute()
> ---
> Insert  after:
> String varStr = varObj==null?"null":varObj.toString();
> the following:
> String msg = "Assign." + name + "=" + varStr;
> if( appLog.isInfoEnabled() )
>appLog.info( msg );

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JEXL-30) ASTAddNode does not add BigDecimal objects correctly

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/JEXL-30?page=comments#action_12451176 ] 

Rahul Akolkar commented on JEXL-30:
---

I agree, Dion. We probably want to fold in similar changes accounting for 
BigIntegers into this ticket.


> ASTAddNode does not add BigDecimal objects correctly
> 
>
> Key: JEXL-30
> URL: http://issues.apache.org/jira/browse/JEXL-30
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: All
>Reporter: Curtis Stanford
>
> The ASTAddNode only checks for Float or Double objects when adding floating 
> point numbers. If the objects are not Float or Double, they are added as 
> Long's. As a result, adding BigDecimal objects loses any existing decimal 
> points.
> Untested patch:
> Index: ASTAddNode.java
> ===
> --- ASTAddNode.java (revision 476204)
> +++ ASTAddNode.java (working copy)
> @@ -16,6 +16,8 @@
>  
>  package org.apache.commons.jexl.parser;
>  
> +import java.math.BigDecimal;
> +
>  import org.apache.commons.jexl.JexlContext;
>  import org.apache.commons.jexl.util.Coercion;
>  
> @@ -71,8 +73,8 @@
>   *  if anything is float, double or string with ( "." | "E" | "e")
>   *  coerce all to doubles and do it
>   */
> -if (left instanceof Float || left instanceof Double
> -|| right instanceof Float || right instanceof Double
> +if (left instanceof Float || left instanceof Double || left 
> instanceof BigDecimal
> +|| right instanceof Float || right instanceof Double || right 
> instanceof BigDecimal
>  || (left instanceof String
>&& (((String) left).indexOf(".") != -1 
>|| ((String) left).indexOf("e") != -1

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-31) Var and Assign to log the result of the evaluation

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-31?page=all ]

Rahul Akolkar updated SCXML-31:
---

Fix Version/s: 0.6
 Assignee: Rahul Akolkar

> Var and Assign to log the result of the evaluation
> --
>
> Key: SCXML-31
> URL: http://issues.apache.org/jira/browse/SCXML-31
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
> Environment: all
>Reporter: Nestor Urquiza
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> Var#execute()
> ---
> Insert  after:
> String varStr = varObj==null?"null":varObj.toString();
> the following:
>  String msg = "Var." + name + "=" + varStr;
> if( appLog.isInfoEnabled() )
>appLog.info( msg );
> Assign#execute()
> ---
> Insert  after:
> String varStr = varObj==null?"null":varObj.toString();
> the following:
> String msg = "Assign." + name + "=" + varStr;
> if( appLog.isInfoEnabled() )
>appLog.info( msg );

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (DIGESTER-108) [digester] [PATCH] Fix for broken links on Digester homepage

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/DIGESTER-108?page=all ]

Rahul Akolkar resolved DIGESTER-108.


Resolution: Fixed
  Assignee: Rahul Akolkar

Fixed in r465050, thanks for the patch.

Please feel free to fix such things yourself, no need to file a ticket IMO. 
I've gone ahead and refreshed the digester website since it still had the AC'05 
banner on it ;-) It should get sync'ed out live in an hour or two.


> [digester] [PATCH] Fix for broken links on Digester homepage
> 
>
> Key: DIGESTER-108
> URL: http://issues.apache.org/jira/browse/DIGESTER-108
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Kris Nuttycombe
> Assigned To: Rahul Akolkar
>Priority: Trivial
> Fix For: Nightly Builds
>
> Attachments: index.xml.patch
>
>
> Just a couple extremely minor fixes for the homepage.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-21) Send an event by delay attribute, with the targettype attribute is absent

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-21?page=all ]

Rahul Akolkar resolved SCXML-21.


Resolution: Fixed
  Assignee: Rahul Akolkar

A new EventDispatcher implementation (SimpleScheduler) that provides the 
ability to deal with delayed events of the "scxml"  targettype has been 
added. Delay will be processed as expected in the comment above if this 
(extensible) EventDispatcher implementation is used.

The delay attribute now supports the following suffixes (ms-milliseconds, 
s-seconds, m-minutes; the default being milliseconds).


> Send an event by delay attribute, with the targettype attribute is absent
> -
>
> Key: SCXML-21
> URL: http://issues.apache.org/jira/browse/SCXML-21
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.5
> Environment: Windows XP Professional (Service Pack 2) - Version: 
> Portuguese
> CPU: Pentium 4; 2,80 GHz; 512 MB
>Reporter: Raimundo Santos Moura
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> There is a bug, when one try to run the code below:
> Scenario: In state "Off", by trigger of the event , i need to wait 10s 
> in state "On"; after this time, i should return to state "Off". The attribute 
>  doesn't work well (seemingly).
>  
>  http://www.w3.org/2005/07/SCXML"; version="1.0" 
>   initialstate="Off">
> 
>  
> 
> 
>   
>   
>   
>   
>   
>   
>   
>   
>
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-28) Support for the pnuts scripting language

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-28?page=comments#action_12440340 ] 

Rahul Akolkar commented on SCXML-28:


Here is the procedure, just in case (helps if a project team member makes the 
JIRA upload request):

 http://maven.apache.org/guides/mini/guide-ibiblio-upload.html


> Support for the pnuts scripting language
> 
>
> Key: SCXML-28
> URL: http://issues.apache.org/jira/browse/SCXML-28
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>Priority: Minor
> Fix For: 1.0
>
> Attachments: PnutsContext.java, PnutsEvaluator.java, 
> PnutsEvaluator.java, PnutsEvaluator.java
>
>
> Add support for the pnuts scripting language.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-28) Support for the pnuts scripting language

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-28?page=comments#action_12440240 ] 

Rahul Akolkar commented on SCXML-28:


I can confirm receipt of your ICLA. Thanks for sending it in.

Once pnuts is in the Maven repository, and a complete patch is available 
(ideally all related changes put together in a single patch file), we can make 
progress here.


> Support for the pnuts scripting language
> 
>
> Key: SCXML-28
> URL: http://issues.apache.org/jira/browse/SCXML-28
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>Priority: Minor
> Fix For: 1.0
>
> Attachments: PnutsContext.java, PnutsEvaluator.java, 
> PnutsEvaluator.java, PnutsEvaluator.java
>
>
> Add support for the pnuts scripting language.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-20) A Suggestion to enhance SCXMLExecutor and SCInstance class to support state persistence

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-20?page=comments#action_12440239 ] 

Rahul Akolkar commented on SCXML-20:


The Commons SCXML Java object model for state machines as well as the 
SCXMLExecutor instances are now Serializable. It'd be great if you could try a 
latest nightly (20061006 and up) from this URL:

 http://people.apache.org/builds/jakarta-commons/nightly/commons-scxml/

and let us know if it similarly works for you (without the proposed 
ExecutorState bits ofcourse). These changes might reduce the need for the 
ExecutorState addition, so I'm leaning towards resolving this issue.


> A Suggestion to enhance SCXMLExecutor and SCInstance class to support state 
> persistence
> ---
>
> Key: SCXML-20
> URL: http://issues.apache.org/jira/browse/SCXML-20
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
> Environment: Windows, JDK 1.4.2 and above
>Reporter: Sitthichai Rernglertpricha
> Fix For: 0.6
>
> Attachments: patches, scxmlservlet.war
>
>
> Currently, SCXMLExecutor and SCInstance does not implement Serializable. 
> Hence, under a clustered application server environment, they cannot be 
> persisted by the application server for session failover.
> Instead of changing SCXMLExecutor and SCInstance to implement Serializable, 
> an alternative is to leverage on the Memento design pattern so that 
> SCXMLExecutor and SCInstance class can persist their states via 2 new 
> saveState() and restoreState() methods. Both methods are passed a new 
> ExecutorState interface object. The SCXMLExecutor and SCInstance class will 
> save their states into the ExecutorState object when their saveState() 
> methods are called, and reload their states from the ExecutorState object 
> when their restoreState() methods are called. Different child implementation 
> of the ExecutorState interface will then handle the actual persistence to 
> appropriate channel, and decide what need to persist and what need not.
> For your consideration, I have attached patches to SCXMLExecutor and 
> SCInstance class with the 2 new saveState() and restoreState() methods, and 
> the new ExecutorState interface class.I have also attached a web application 
> (tested under Geronimo ) illustrating an implementation under Servlet 
> environment. Please refer to the readme.txt in the WAR file for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-30) Better handling of parent/child relationsships

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-30?page=all ]

Rahul Akolkar updated SCXML-30:
---

Fix Version/s: 1.0

Makes good sense to do this. One can think of two "views" of state machines 
from a Commons SCXML perspective:

(a) A document-centric view: This is the n-ary tree represented by the SCXML 
document. The top-down relationships from document root are important
(b) A engine-centric view: This is an intricate graph with all the wires 
between transition targets and initials and histories drawn out on top of the 
n-ary tree in (a)

For version 0.5, the focus has been to take (a) and the wiring needed to 
transform it into (b) was done as a separate step. While this will continue to 
hold to some extent, the consistency and conveniences needed for procedural 
tweaking of the object model (such as setting symmetric references) are 
definitely desirable, though it might mean we lose the side-effect free setters 
in some cases. While it may not be obvious, SCXML-23 has the beginnings of such 
an effort.

I am setting the fix version to 1.0 primarily because, on a strict 
prioritization basis, this lags behind other things I want to do. However, if 
anyone fancies a tested patch, there is no reason not to apply it immediately.


> Better handling of parent/child relationsships
> --
>
> Key: SCXML-30
> URL: http://issues.apache.org/jira/browse/SCXML-30
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
> Fix For: 1.0
>
>
> The nice thing about Statecharts is its hierarchical structure. However, it 
> is far too easy to build incomplete models, e.g. use addChild but forget 
> setParent. I notice that some add methods automatically set the parent 
> (opposite relation), and I suggest that this is done consistently throughout 
> the model classes. This also goes for methods like State.setParallel and 
> Parallel(TransitionTarget).setParent.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-29) Object model should be Serializable

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-29?page=all ]

Rahul Akolkar resolved SCXML-29.


Resolution: Fixed

> Object model should be Serializable
> ---
>
> Key: SCXML-29
> URL: http://issues.apache.org/jira/browse/SCXML-29
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> Refactor the model package as needed for Java serializability. Add JUnit test 
> cases to ensure this.
> Goes hand-in-hand with SCXML-20.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-28) Support for the pnuts scripting language

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-28?page=comments#action_12439599 ] 

Rahul Akolkar commented on SCXML-28:


Thanks. Reponses numbered same as earlier post:

3) The site sources are in the xdocs/ directory:

 http://svn.apache.org/repos/asf/jakarta/commons/proper/scxml/trunk/xdocs/

You can submit patches to the site sources, see this page for more on producing 
patches in the appropriate format:

 http://jakarta.apache.org/commons/patches.html

4) Let us know how that goes.

I will follow up and confirm receipt of the ICLA (will require a few days).



> Support for the pnuts scripting language
> 
>
> Key: SCXML-28
> URL: http://issues.apache.org/jira/browse/SCXML-28
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>Priority: Minor
> Fix For: 1.0
>
> Attachments: PnutsContext.java, PnutsEvaluator.java, 
> PnutsEvaluator.java, PnutsEvaluator.java
>
>
> Add support for the pnuts scripting language.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-29) Object model should be Serializable

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-29?page=all ]

Rahul Akolkar updated SCXML-29:
---

Fix Version/s: 0.6

Lets shoot for this in 0.6.


> Object model should be Serializable
> ---
>
> Key: SCXML-29
> URL: http://issues.apache.org/jira/browse/SCXML-29
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> Refactor the model package as needed for Java serializability. Add JUnit test 
> cases to ensure this.
> Goes hand-in-hand with SCXML-20.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-29) Object model should be Serializable

[Rahul Akolkar (JIRA)]

Object model should be Serializable
---

 Key: SCXML-29
 URL: http://issues.apache.org/jira/browse/SCXML-29
 Project: Commons SCXML
  Issue Type: Improvement
Affects Versions: 0.5
Reporter: Rahul Akolkar


Refactor the model package as needed for Java serializability. Add JUnit test 
cases to ensure this.

Goes hand-in-hand with SCXML-20.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-28) Support for the pnuts scripting language

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-28?page=comments#action_12439578 ] 

Rahul Akolkar commented on SCXML-28:


Thanks for your time and the changes. Few comments:

1) The addition of Javadocs has introduced @author tags. Commons SCXML code 
does not contain those tags, the only attribution is the list on the team page 
on the website. The tags will need to be removed before this gets into the 
codebase, if it is accepted.
2) There are no test cases. Please look at the test suite and provide some test 
SCXML documents using pnuts along with the JUnit test cases.
3) We will also need to update the site documentation (such as the section on 
contexts and evaluators in the user guide) at the same time.
4) Is pnuts in a Maven 1 repository somewhere? If not, we will need that to 
happen first (might involve pinging the pnuts lists, are you subscribed there?).

Finally, please let us know when your ICLA is sent and we can come back to this 
ticket then.


> Support for the pnuts scripting language
> 
>
> Key: SCXML-28
> URL: http://issues.apache.org/jira/browse/SCXML-28
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>Priority: Minor
> Fix For: 1.0
>
> Attachments: PnutsContext.java, PnutsEvaluator.java, 
> PnutsEvaluator.java, PnutsEvaluator.java
>
>
> Add support for the pnuts scripting language.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-27) Improve possibility to extending (subclassing) the default semantics

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-27?page=comments#action_12439571 ] 

Rahul Akolkar commented on SCXML-27:


Let me state my assertions behind resolving this as won't fix:

a) The class in question has non-trivial functionality
b) We tried to make it pluggable, exactly for these kind of usecases
c) Custom semantics is considered advanced API for the library
d) The existing method signatures and call stack cannot be compromised
e) Because of (a) and (d), some (or many) cases might require subclasses to 
indulge in copious copy-paste to find the correct insertion points
f) I personally expect advanced users to be somewhat more tolerant than casual 
users
g) Making a particular change that makes sense for any one usecase does not 
solve this issue eternally

To reopen this ticket, therefore, we need a complete proposal stating how:

a) Subclassing convenience has improved for many (if not all) usecases 
(preferred way to illustrate is test cases)
b) All existing API contracts are preserved
c) The changes (additions, really) constitute the minimal essential set

This is not to say your suggestion may not have merit for your usecase, it 
does, but these are the (more important) broader constraints.

> Improve possibility to extending (subclassing) the default semantics
> 
>
> Key: SCXML-27
> URL: http://issues.apache.org/jira/browse/SCXML-27
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>
> I've extended the default SCXML semantics (subclassed SCXMLSemanticsImpl) 
> with a more flexible event matching method. However, this required copying a 
> lot of code from SCXMLSemanticsImpl, just to replace the event matching 
> method. The problem was that the eventMatch method takes String and Set 
> arguments, with no way to get at the Transition who's event is to be tested. 
> I copied the relevant code and replaced eventMatch(String,Set) with 
> eventMatch(Transition,Set), to make it more flexible. I ask that this change 
> is made to SCXMLSemanticsImpl, to better support overriding.
> The flexibility I've added is to use regular expressions for matching, and 
> since this happens often, I wanted to cache the compiled pattern. The natural 
> place to do this is the Transition, so I subclassed the Transition class, 
> included a field for holding the compiled pattern and made sure to use this 
> subclass whenever a regexp was needed. Then in the modified eventMatch code, 
> I check whether the Transition is of this subclass and used the cache to 
> improve performance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-26) Add parameter to Evaluator.newContext

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-26?page=comments#action_12439566 ] 

Rahul Akolkar commented on SCXML-26:


Indeed we're aware that SCXML will be at its productive best when its used in 
particular contexts, not in isolation. In terms of the two options from your 
last comment, #1 (query an SCXMLExecutor instance for the context corresponding 
to a target) is feasible, and I think would be a useful addition. For #2, its 
true that Evaluators may need more, but the interface provides the bare minimum 
(anything else should be part of the implementation).


> Add parameter to Evaluator.newContext
> -
>
> Key: SCXML-26
> URL: http://issues.apache.org/jira/browse/SCXML-26
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
> Fix For: 1.0
>
>
> The Evaluator.newContext method currently takes one argument, the parent 
> context. However, to make it easier for the context to link to relevant 
> application data, it would be nice if it also took a TransitionTarget 
> argument, i.e. have the signature public Context 
> newContext(TransitionTarget target, Context parent); By including the target 
> in the context, it becomes easier for expressions to refer to contextual 
> data. In my case, SCXML is used together with data bindings, and expressions 
> are used to refer to data in the context of states and transitions. I had to 
> modify SCXML as suggested above, to provide the link between state and data 
> bindings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-28) Support for the pnuts scripting language

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-28?page=comments#action_12439225 ] 

Rahul Akolkar commented on SCXML-28:


Could you also fill out an Individual Contributor License Agreement (ICLA) for 
this? That is here (the fax number is on the form itself, you can mail it in 
too if you want):

 http://www.apache.org/licenses/icla.txt

While it might seem like a barrier, its a one-time thing, and is needed for 
contributions such as this one which may contain new source files, for 
provenance and pedigree reasons. Let us know if you have any questions, thanks.



> Support for the pnuts scripting language
> 
>
> Key: SCXML-28
> URL: http://issues.apache.org/jira/browse/SCXML-28
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>Priority: Minor
> Fix For: 1.0
>
> Attachments: PnutsEvaluator.java
>
>
> Add support for the pnuts scripting language.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-25) Deprecate static fields in ErrorReporter

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-25?page=comments#action_12439222 ] 

Rahul Akolkar commented on SCXML-25:


Deprecated in r452118 while at 0.6-SNAPSHOT.


> Deprecate static fields in ErrorReporter
> 
>
> Key: SCXML-25
> URL: http://issues.apache.org/jira/browse/SCXML-25
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 1.0
>
>
> Leaky abstraction, function of particular SCXMLSemantics impl. As a preferred 
> alternative, provide ErrorConstants (or some such name) for default impl.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-28) Support for the pnuts scripting language

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-28?page=all ]

Rahul Akolkar updated SCXML-28:
---

Fix Version/s: 1.0

Thanks for your time and contribution, looks good.

Additionally, it would be very nice of you if you could please:
a) Add the ASLv2 license header to the file (see any other Commons SCXML file)
b) Separate the Evaluator and Context impl in two separate source files (each 
with license headers, like the jsp or jexl packages)
c) Remove any non Commons SCXML class references from the code
d) Correct package name (suggest org.apache.commons.scxml.env.pnuts)
e) Add Javadocs

That would probably complete the contribution, IMO (barring anything I've 
missed here). Thanks again.



> Support for the pnuts scripting language
> 
>
> Key: SCXML-28
> URL: http://issues.apache.org/jira/browse/SCXML-28
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>Priority: Minor
> Fix For: 1.0
>
> Attachments: PnutsEvaluator.java
>
>
> Add support for the pnuts scripting language.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-27) Improve possibility to extending (subclassing) the default semantics

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-27?page=all ]

Rahul Akolkar resolved SCXML-27.


Resolution: Won't Fix

Its probably the natural place to put the compiled pattern, but subclassing the 
Transition class probably requires changes in other places (we generally do not 
recommend subclassing anything in the model package, since it can have 
collateral in the digester, semantics etc.)

Might be best to maintain an independent cache here.


> Improve possibility to extending (subclassing) the default semantics
> 
>
> Key: SCXML-27
> URL: http://issues.apache.org/jira/browse/SCXML-27
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
>
> I've extended the default SCXML semantics (subclassed SCXMLSemanticsImpl) 
> with a more flexible event matching method. However, this required copying a 
> lot of code from SCXMLSemanticsImpl, just to replace the event matching 
> method. The problem was that the eventMatch method takes String and Set 
> arguments, with no way to get at the Transition who's event is to be tested. 
> I copied the relevant code and replaced eventMatch(String,Set) with 
> eventMatch(Transition,Set), to make it more flexible. I ask that this change 
> is made to SCXMLSemanticsImpl, to better support overriding.
> The flexibility I've added is to use regular expressions for matching, and 
> since this happens often, I wanted to cache the compiled pattern. The natural 
> place to do this is the Transition, so I subclassed the Transition class, 
> included a field for holding the compiled pattern and made sure to use this 
> subclass whenever a regexp was needed. Then in the modified eventMatch code, 
> I check whether the Transition is of this subclass and used the cache to 
> improve performance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-26) Add parameter to Evaluator.newContext

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-26?page=all ]

Rahul Akolkar updated SCXML-26:
---

Fix Version/s: 1.0

Conceptually, there is a 1:1 mapping between contexts and targets, as 
established by the executor instance, which picks the target for the new 
context.

This is a major change request (anytime a change is requested to an interface 
which is part of the component's public API), so it definitely won't happen 
before a 1.0 release (and even if it happens at a 1.0, might require a 
subinterface and fancy footwork in code) -- so we'll need to have quite a 
compelling argument, thats unclear to me at the moment.



> Add parameter to Evaluator.newContext
> -
>
> Key: SCXML-26
> URL: http://issues.apache.org/jira/browse/SCXML-26
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
>Reporter: Hallvard Trætteberg
> Fix For: 1.0
>
>
> The Evaluator.newContext method currently takes one argument, the parent 
> context. However, to make it easier for the context to link to relevant 
> application data, it would be nice if it also took a TransitionTarget 
> argument, i.e. have the signature public Context 
> newContext(TransitionTarget target, Context parent); By including the target 
> in the context, it becomes easier for expressions to refer to contextual 
> data. In my case, SCXML is used together with data bindings, and expressions 
> are used to refer to data in the context of states and transitions. I had to 
> modify SCXML as suggested above, to provide the link between state and data 
> bindings.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-22) The engine must report error/warning when invalid events are triggered

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-22?page=all ]

Rahul Akolkar updated SCXML-22:
---

Fix Version/s: 0.6

Related discussion thread:

http://www.nabble.com/-SCXML---error-reporting-on-invalid-events-tf2343519.html


> The engine must report error/warning when invalid events are triggered
> --
>
> Key: SCXML-22
> URL: http://issues.apache.org/jira/browse/SCXML-22
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
> Environment: Win XP Professional, jdk 1.4.02
>Reporter: Raj Rao
> Fix For: 0.6
>
>
> The semantics must report an error/warning/notification when an invalid event 
> is triggered, instead of silently discarding it. An invalid event is one that 
> is not specified for the current state.
> Here's an excerpt of a converstaion, where the suggested workaround was not 
> applicable. This requirement is crucial for me.
> --
> Raj
> --
> > Hello,
> >
> > I tried sending an invalid event to the state machine
> > and didn't see any error being reported. By invalid I
> > mean this event was not expected in the current state.
> >
> > Does the SCXMLSemanticsImpl report an error (via the
> > the ErrorReporter) when such an event is silently
> > discarded?
> >
> 
> No, because the semantics treat it as simply an inconsequential
> trigger (causing no change to the state machine), rather than an
> error.
> One of the ways you could track this is to register a SCXMLListener on
> the executor and track onTransition() callbacks (if you get none, the
> trigger is "invalid" -- per your definition above).
> -Rahul

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-25) Deprecate static fields in ErrorReporter

[Rahul Akolkar (JIRA)]

Deprecate static fields in ErrorReporter


 Key: SCXML-25
 URL: http://issues.apache.org/jira/browse/SCXML-25
 Project: Commons SCXML
  Issue Type: Bug
Affects Versions: 0.5
Reporter: Rahul Akolkar
 Assigned To: Rahul Akolkar
 Fix For: 1.0


Leaky abstraction, function of particular SCXMLSemantics impl. As a preferred 
alternative, provide ErrorConstants (or some such name) for default impl.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-24) Add (and remove) CustomDigester

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-24?page=all ]

Rahul Akolkar updated SCXML-24:
---

Fix Version/s: 0.6

Tentatively set fix version to 0.6.


> Add (and remove) CustomDigester
> ---
>
> Key: SCXML-24
> URL: http://issues.apache.org/jira/browse/SCXML-24
> Project: Commons SCXML
>  Issue Type: Task
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 0.6
>
>
> Based on my allergic reaction to snapshot dependencies, lets introduce a 
> CustomDigester class (package scoped in the oacs.io package) which 
> essentially subclasses Digester and adds DIGESTER-107 functionality (which is 
> currently in digester trunk). Furthermore, remember to remove this class if 
> and when we see the next Digester release.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-24) Add (and remove) CustomDigester

[Rahul Akolkar (JIRA)]

Add (and remove) CustomDigester
---

 Key: SCXML-24
 URL: http://issues.apache.org/jira/browse/SCXML-24
 Project: Commons SCXML
  Issue Type: Task
Affects Versions: 0.5
Reporter: Rahul Akolkar


Based on my allergic reaction to snapshot dependencies, lets introduce a 
CustomDigester class (package scoped in the oacs.io package) which essentially 
subclasses Digester and adds DIGESTER-107 functionality (which is currently in 
digester trunk). Furthermore, remember to remove this class if and when we see 
the next Digester release.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-23) Deprecate digester rules

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-23?page=comments#action_12438766 ] 

Rahul Akolkar commented on SCXML-23:


Marked deprecated in r451364 while at 0.6-SNAPSHOT.


> Deprecate digester rules
> 
>
> Key: SCXML-23
> URL: http://issues.apache.org/jira/browse/SCXML-23
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.5
>Reporter: Rahul Akolkar
> Assigned To: Rahul Akolkar
> Fix For: 1.0
>
>
> For no reason (well, other than oversight) digester rules are public. Its 
> unlikely anyone uses those since they're the internal guts, but need to start 
> the deprecation cycle nevertheless and downgrade visibility in 1.0.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (SCXML-23) Deprecate digester rules

[Rahul Akolkar (JIRA)]

Deprecate digester rules


 Key: SCXML-23
 URL: http://issues.apache.org/jira/browse/SCXML-23
 Project: Commons SCXML
  Issue Type: Bug
Affects Versions: 0.5
Reporter: Rahul Akolkar
 Fix For: 1.0


For no reason (well, other than oversight) digester rules are public. Its 
unlikely anyone uses those since they're the internal guts, but need to start 
the deprecation cycle nevertheless and downgrade visibility in 1.0.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-22) The engine must report error/warning when invalid events are triggered

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-22?page=comments#action_12438470 ] 

Rahul Akolkar commented on SCXML-22:


There is no such requirement for an SCXML engine, but its useful feedback I 
agree. Two questions:
(a) While the workaround is clearly just that, can you elaborate why its not 
applicable for you?
(b) Generally speaking, this is application specific behavior as far as Commons 
SCXML is concerned, so we can't hardcode an error/warning (or anything else for 
that matter). What would be a good way to receive that feedback, for your 
usecase? 


> The engine must report error/warning when invalid events are triggered
> --
>
> Key: SCXML-22
> URL: http://issues.apache.org/jira/browse/SCXML-22
> Project: Commons SCXML
>  Issue Type: Improvement
>Affects Versions: 0.5
> Environment: Win XP Professional, jdk 1.4.02
>Reporter: Raj Rao
>
> The semantics must report an error/warning/notification when an invalid event 
> is triggered, instead of silently discarding it. An invalid event is one that 
> is not specified for the current state.
> Here's an excerpt of a converstaion, where the suggested workaround was not 
> applicable. This requirement is crucial for me.
> --
> Raj
> --
> > Hello,
> >
> > I tried sending an invalid event to the state machine
> > and didn't see any error being reported. By invalid I
> > mean this event was not expected in the current state.
> >
> > Does the SCXMLSemanticsImpl report an error (via the
> > the ErrorReporter) when such an event is silently
> > discarded?
> >
> 
> No, because the semantics treat it as simply an inconsequential
> trigger (causing no change to the state machine), rather than an
> error.
> One of the ways you could track this is to register a SCXMLListener on
> the executor and track onTransition() callbacks (if you get none, the
> trigger is "invalid" -- per your definition above).
> -Rahul

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (JEXL-24) Support Long for integer literal instead of Integers

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/JEXL-24?page=comments#action_12437872 ] 

Rahul Akolkar commented on JEXL-24:
---

The patch seems to contain some noise (such as removing a license header, 
formatting changes?), but the crux (using Longs here) is better, and also 
aligns with EL.

However, note that we have to change the test cases accordingly, which makes me 
wonder whether any users could be similarly relying on the fact that these are 
Integers, and hence, I'm not too comfortable for this to be part of a point 
release. The next minor release? What do you think?

In general, number format exceptions are a language limitation, and there is 
only so much to be done about those (ofcourse, we want to move to Longs in this 
particular case at some point, but even that is going to have a cap).


> Support Long for integer literal instead of Integers
> 
>
> Key: JEXL-24
> URL: http://issues.apache.org/jira/browse/JEXL-24
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: dion gillard
>Priority: Minor
> Fix For: 1.1.1
>
> Attachments: JEXL-24.patch.txt
>
>
> Manisha Athavale reports:
> Hello,
>  We use the jexl 1.1 jar for simple expression evaluation. The parser 
> throws number format exception when gave expression like "3988514195 - SP". 
> What is the limit for constants used in expression? Actually, there should 
> not be any limit for constants in the expression, is it correct?
> Integer literals (such as the one above) are bound by Integer.MAX_VALUE. You 
> may have better luck changing the value to 3988514195.0
> Consider this a request for integer literals to be stored as Longs

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (DIGESTER-107) Provide ability to capture namespace snapshots

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/DIGESTER-107?page=all ]

Rahul Akolkar resolved DIGESTER-107.


Resolution: Fixed

Committed to trunk in r449882. Resolving as Fixed.


> Provide ability to capture namespace snapshots
> --
>
> Key: DIGESTER-107
> URL: http://issues.apache.org/jira/browse/DIGESTER-107
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Rahul Akolkar
> Attachments: DIGESTER-107-01.patch, DIGESTER-107-02.patch, 
> DIGESTER-107.patch
>
>
> Attached patch adds the capability to snapshot current namespaces at any 
> point during parsing. This is useful, for example, in Commons SCXML where the 
> value of an attribute can contain an XPath expression which needs to be 
> evaluated later. The testcase in the patch captures namespace snapshots for 
> each object created by the digester. Feedback welcome.
> As an aside, does anyone mind if I bring the Digester JIRA versions up to 
> date? Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (DIGESTER-107) Provide ability to capture namespace snapshots

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/DIGESTER-107?page=all ]

Rahul Akolkar updated DIGESTER-107:
---

Attachment: DIGESTER-107-02.patch

Revised patch per earlier comment.

> Provide ability to capture namespace snapshots
> --
>
> Key: DIGESTER-107
> URL: http://issues.apache.org/jira/browse/DIGESTER-107
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Rahul Akolkar
> Attachments: DIGESTER-107-01.patch, DIGESTER-107-02.patch, 
> DIGESTER-107.patch
>
>
> Attached patch adds the capability to snapshot current namespaces at any 
> point during parsing. This is useful, for example, in Commons SCXML where the 
> value of an attribute can contain an XPath expression which needs to be 
> evaluated later. The testcase in the patch captures namespace snapshots for 
> each object created by the digester. Feedback welcome.
> As an aside, does anyone mind if I bring the Digester JIRA versions up to 
> date? Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (DIGESTER-107) Provide ability to capture namespace snapshots

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/DIGESTER-107?page=comments#action_12437217 
] 

Rahul Akolkar commented on DIGESTER-107:


Correct, I should've checked the type heirarchy for ESE. In any case, a 
RuntimeException shouldn't happen if the Digester "namespaces" book-keeping 
goes according to plan. I'll attach another patch in a minute.


> Provide ability to capture namespace snapshots
> --
>
> Key: DIGESTER-107
> URL: http://issues.apache.org/jira/browse/DIGESTER-107
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Rahul Akolkar
> Attachments: DIGESTER-107-01.patch, DIGESTER-107.patch
>
>
> Attached patch adds the capability to snapshot current namespaces at any 
> point during parsing. This is useful, for example, in Commons SCXML where the 
> value of an attribute can contain an XPath expression which needs to be 
> evaluated later. The testcase in the patch captures namespace snapshots for 
> each object created by the digester. Feedback welcome.
> As an aside, does anyone mind if I bring the Digester JIRA versions up to 
> date? Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (DIGESTER-107) Provide ability to capture namespace snapshots

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/DIGESTER-107?page=all ]

Rahul Akolkar updated DIGESTER-107:
---

Attachment: DIGESTER-107-01.patch

Patch that limits changes to getCurrentNamespaces() method. Test case is the 
same as the earlier patch.


> Provide ability to capture namespace snapshots
> --
>
> Key: DIGESTER-107
> URL: http://issues.apache.org/jira/browse/DIGESTER-107
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Rahul Akolkar
> Attachments: DIGESTER-107-01.patch, DIGESTER-107.patch
>
>
> Attached patch adds the capability to snapshot current namespaces at any 
> point during parsing. This is useful, for example, in Commons SCXML where the 
> value of an attribute can contain an XPath expression which needs to be 
> evaluated later. The testcase in the patch captures namespace snapshots for 
> each object created by the digester. Feedback welcome.
> As an aside, does anyone mind if I bring the Digester JIRA versions up to 
> date? Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (DIGESTER-107) Provide ability to capture namespace snapshots

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/DIGESTER-107?page=comments#action_12437150 
] 

Rahul Akolkar commented on DIGESTER-107:


Thanks for the feedback. WRT the earlier patch:

 * I had the new members protected since to achieve the "caching" effect of the 
currentNamespaces member, the implementation spilt out into other methods 
(start/endPrefixMapping() -- not just getCurrentNamespaces()) and was tied at 
the hip to the namespaces member (for the dirty flag) and therefore leaving the 
new members private (when namespaces is protected) would possibly leave 
subclasses in a wicked predicament.

 * The modifiability of the map may be better left to the semantics of the 
object model that the document gets parsed into, and I presumed it may be 
useful to have a namespaces snapshot that one can work with as one pleases, 
depending on the usecase (actually, a new instance is not created in the 
earlier patch, the old one is cleared -- but that could easily be changed).

Moving forward, I wonder whether the caching has any noticeable benefit (I have 
no measurements either way) and another proposal would be to not add any new 
members at all, and let getCurrentNamespaces() do all the work each time. I'll 
attach such a patch in a few minutes. Let me know which one you'd prefer, 
thanks!


> Provide ability to capture namespace snapshots
> --
>
> Key: DIGESTER-107
> URL: http://issues.apache.org/jira/browse/DIGESTER-107
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Rahul Akolkar
> Attachments: DIGESTER-107.patch
>
>
> Attached patch adds the capability to snapshot current namespaces at any 
> point during parsing. This is useful, for example, in Commons SCXML where the 
> value of an attribute can contain an XPath expression which needs to be 
> evaluated later. The testcase in the patch captures namespace snapshots for 
> each object created by the digester. Feedback welcome.
> As an aside, does anyone mind if I bring the Digester JIRA versions up to 
> date? Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (DIGESTER-107) Provide ability to capture namespace snapshots

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/DIGESTER-107?page=all ]

Rahul Akolkar updated DIGESTER-107:
---

Attachment: DIGESTER-107.patch

Suggested improvement to capture namespace snapshots and related test case.


> Provide ability to capture namespace snapshots
> --
>
> Key: DIGESTER-107
> URL: http://issues.apache.org/jira/browse/DIGESTER-107
> Project: Commons Digester
>  Issue Type: Improvement
>Affects Versions: Nightly Builds
>Reporter: Rahul Akolkar
> Attachments: DIGESTER-107.patch
>
>
> Attached patch adds the capability to snapshot current namespaces at any 
> point during parsing. This is useful, for example, in Commons SCXML where the 
> value of an attribute can contain an XPath expression which needs to be 
> evaluated later. The testcase in the patch captures namespace snapshots for 
> each object created by the digester. Feedback welcome.
> As an aside, does anyone mind if I bring the Digester JIRA versions up to 
> date? Thanks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (DIGESTER-107) Provide ability to capture namespace snapshots

[Rahul Akolkar (JIRA)]

Provide ability to capture namespace snapshots
--

 Key: DIGESTER-107
 URL: http://issues.apache.org/jira/browse/DIGESTER-107
 Project: Commons Digester
  Issue Type: Improvement
Affects Versions: Nightly Builds
Reporter: Rahul Akolkar


Attached patch adds the capability to snapshot current namespaces at any point 
during parsing. This is useful, for example, in Commons SCXML where the value 
of an attribute can contain an XPath expression which needs to be evaluated 
later. The testcase in the patch captures namespace snapshots for each object 
created by the digester. Feedback welcome.

As an aside, does anyone mind if I bring the Digester JIRA versions up to date? 
Thanks.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (EL-14) Property type incorrectly interpreted

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/EL-14?page=all ]

Rahul Akolkar resolved EL-14.
-

Resolution: Invalid

Behavior is per spec. Resolving as Invalid.

Solution is to use String type for "status" property.


> Property type incorrectly interpreted
> -
>
> Key: EL-14
> URL: http://issues.apache.org/jira/browse/EL-14
> Project: Commons EL
>  Issue Type: Bug
>Affects Versions: 1.0 Final
> Environment: JBoss 4.0.4.GA
> MyFaces 1.1.3
> Tomahawk+Sandbox 1.1.5 snapshot
> Commons EL 1.0
>Reporter: RD
>
>  headerClass="standardTable_Header" footerClass="standardTable_Header"
> rowClasses="standardTable_Row1,standardTable_Row2"
> columnClasses="standardTable_ColumnCentered"
> var="vertrag" value="#{vertragListBean.vertragList}"
> preserveDataModel="true" rows="20"
> sortColumn="#{vertragListBean.sort}"
> sortAscending="#{vertragListBean.ascending}"
> preserveSort="true">
>  rendered="#{vertrag.status == 'A' || vertrag.status == 'a'}">
> private List vertragList =new ArrayList();
> public List getVertragList() {
> doFilter();
> doSort(getSort(),isAscending());
> return vertragList;
> }
> public class Vertrag implements Serializable {
> private Character status;
> ...
> public Character getStatus() {
> return status;
> }
> public void setStatus(Character status) {
> this.status = status;
> }
> ...
> }
> This generates the following error message:
> javax.faces.el.EvaluationException: Cannot get value for expression 
> '#{vertrag.status == 'A' || vertrag.status == 'a'}'
> at org.apache.myfaces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:402)
> at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1076)
> at 
> org.apache.myfaces.component.html.ext.HtmlCommandLink.isRendered(HtmlCommandLink.java:155)
> at 
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:428)
> at 
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChildren(RendererUtils.java:419)
> at 
> org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils.renderChild(RendererUtils.java:440)
> ...
> Caused by: javax.servlet.jsp.el.ELException: An exception occured trying to 
> convert String "A" to type "java.lang.Long"
> at org.apache.commons.el.Logger.logError(Logger.java:481)
> at org.apache.commons.el.Logger.logError(Logger.java:498)
> at org.apache.commons.el.Logger.logError(Logger.java:566)
> at org.apache.commons.el.Coercions.coerceToPrimitiveNumber(Coercions.java:440)
> at org.apache.commons.el.Coercions.applyEqualityOperator(Coercions.java:1052)
> at org.apache.commons.el.EqualityOperator.apply(EqualityOperator.java:81)
> at 
> org.apache.commons.el.BinaryOperatorExpression.evaluate(BinaryOperatorExpression.java:170)
> What can I do to solve this?
> Note: I have posted this issue in MyFaces Tomahawk and have got the following 
> message from Martin Marinschek:
> "Looks to me like a bug in commons-el. Can you reconfirm with the 
> developer-group of the expression language?"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-21) Send an event by delay attribute, with the targettype attribute is absent

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-21?page=all ]

Rahul Akolkar updated SCXML-21:
---

Fix Version/s: 0.6

> Send an event by delay attribute, with the targettype attribute is absent
> -
>
> Key: SCXML-21
> URL: http://issues.apache.org/jira/browse/SCXML-21
> Project: Commons SCXML
>  Issue Type: Bug
>Affects Versions: 0.5
> Environment: Windows XP Professional (Service Pack 2) - Version: 
> Portuguese
> CPU: Pentium 4; 2,80 GHz; 512 MB
>Reporter: Raimundo Santos Moura
> Fix For: 0.6
>
>
> There is a bug, when one try to run the code below:
> Scenario: In state "Off", by trigger of the event , i need to wait 10s 
> in state "On"; after this time, i should return to state "Off". The attribute 
>  doesn't work well (seemingly).
>  
>  http://www.w3.org/2005/07/SCXML"; version="1.0" 
>   initialstate="Off">
> 
>  
> 
> 
>   
>   
>   
>   
>   
>   
>   
>   
>
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-20) A Suggestion to enhance SCXMLExecutor and SCInstance class to support state persistence

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-20?page=all ]

Rahul Akolkar updated SCXML-20:
---

Fix Version/s: 0.6

> A Suggestion to enhance SCXMLExecutor and SCInstance class to support state 
> persistence
> ---
>
> Key: SCXML-20
> URL: http://issues.apache.org/jira/browse/SCXML-20
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
> Environment: Windows, JDK 1.4.2 and above
>Reporter: Sitthichai Rernglertpricha
> Fix For: 0.6
>
> Attachments: patches, scxmlservlet.war
>
>
> Currently, SCXMLExecutor and SCInstance does not implement Serializable. 
> Hence, under a clustered application server environment, they cannot be 
> persisted by the application server for session failover.
> Instead of changing SCXMLExecutor and SCInstance to implement Serializable, 
> an alternative is to leverage on the Memento design pattern so that 
> SCXMLExecutor and SCInstance class can persist their states via 2 new 
> saveState() and restoreState() methods. Both methods are passed a new 
> ExecutorState interface object. The SCXMLExecutor and SCInstance class will 
> save their states into the ExecutorState object when their saveState() 
> methods are called, and reload their states from the ExecutorState object 
> when their restoreState() methods are called. Different child implementation 
> of the ExecutorState interface will then handle the actual persistence to 
> appropriate channel, and decide what need to persist and what need not.
> For your consideration, I have attached patches to SCXMLExecutor and 
> SCInstance class with the 2 new saveState() and restoreState() methods, and 
> the new ExecutorState interface class.I have also attached a web application 
> (tested under Geronimo ) illustrating an implementation under Servlet 
> environment. Please refer to the readme.txt in the WAR file for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-19) Need to resume a state machine from a specified state

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-19?page=all ]

Rahul Akolkar updated SCXML-19:
---

Fix Version/s: 1.0

> Need to resume a state machine from a specified state
> -
>
> Key: SCXML-19
> URL: http://issues.apache.org/jira/browse/SCXML-19
> Project: Commons SCXML
>  Issue Type: Wish
>Affects Versions: 0.5
> Environment: Win XP, JDK 1.5
>Reporter: Raj Rao
> Fix For: 1.0
>
> Attachments: AbstractStateMachine.java
>
>
> I want a feature that does the following:
> 1.  Consider a state transition from S1 -> S2 -> S3 -> S4, the initial state 
> being "S1".
> 2.  Instantiate a state machine and set its initial state to "S3" 
> 3. Basically, I am resuming the state machine to start from state "S3", and I 
> don't want the engine to invoke the OnEntry executable content  applicable to 
> state "S3". I also want to prevent any EntryListeners from being executed on 
> resuming the state machine from state "S3". Here the assumption is that the 
> state machine had earlier run from "S1" to "S3", and at a later point in time 
> I want to resume the state machine from "S3".
> Currently, the OnEntry and EntryListeners are executed when I set the new 
> initial start state in the state machine and do a engine.go()
> I have attached a modifed AbstractStateMachine.java where I attempted to 
> disable the EntryListeners on a resume.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (JEXL-20) Fix checkstyle issues in 1.1

[Rahul Akolkar (JIRA)]

Fix checkstyle issues in 1.1


 Key: JEXL-20
 URL: http://issues.apache.org/jira/browse/JEXL-20
 Project: Commons JEXL
  Issue Type: Task
Affects Versions: 1.1
Reporter: Rahul Akolkar
 Fix For: 1.1.1


JEXL 1.1 checkstyle is not clean.

Reporter: Phil Steitz


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-20) A Suggestion to enhance SCXMLExecutor and SCInstance class to support state persistence

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-20?page=comments#action_12433489 ] 

Rahul Akolkar commented on SCXML-20:


Cool, perhaps we should place a link to this issue from the related question on 
the wiki FAQ page. This is also somewhat related to SCXML-19.

Generally speaking, I'd favor this approach because it seems unlikely that any 
particular single save/restore mechanism will be acceptable for all usecases. 
I'll take a look at this in further detail late next week.

Thanks a lot for the patch and the servlet-based web flow usecase. Such a 
usecase would also make for a fitting addition to the usecases section on the 
Commons SCXML website (if you're interested, the webpages are in the xdcos 
directory). I should also add a Spring MVC based usecase there.


> A Suggestion to enhance SCXMLExecutor and SCInstance class to support state 
> persistence
> ---
>
> Key: SCXML-20
> URL: http://issues.apache.org/jira/browse/SCXML-20
> Project: Commons SCXML
>  Issue Type: New Feature
>Affects Versions: 0.5
> Environment: Windows, JDK 1.4.2 and above
>Reporter: Sitthichai Rernglertpricha
> Attachments: patches, scxmlservlet.war
>
>
> Currently, SCXMLExecutor and SCInstance does not implement Serializable. 
> Hence, under a clustered application server environment, they cannot be 
> persisted by the application server for session failover.
> Instead of changing SCXMLExecutor and SCInstance to implement Serializable, 
> an alternative is to leverage on the Memento design pattern so that 
> SCXMLExecutor and SCInstance class can persist their states via 2 new 
> saveState() and restoreState() methods. Both methods are passed a new 
> ExecutorState interface object. The SCXMLExecutor and SCInstance class will 
> save their states into the ExecutorState object when their saveState() 
> methods are called, and reload their states from the ExecutorState object 
> when their restoreState() methods are called. Different child implementation 
> of the ExecutorState interface will then handle the actual persistence to 
> appropriate channel, and decide what need to persist and what need not.
> For your consideration, I have attached patches to SCXMLExecutor and 
> SCInstance class with the 2 new saveState() and restoreState() methods, and 
> the new ExecutorState interface class.I have also attached a web application 
> (tested under Geronimo ) illustrating an implementation under Servlet 
> environment. Please refer to the readme.txt in the WAR file for more details.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-18) Refactoring of Evaluator.execLocation

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-18?page=all ]

Rahul Akolkar resolved SCXML-18.


Resolution: Won't Fix

The association to a Node is via the WD itself (it talks about XML data trees, 
and appending/relocating subtrees à la DOM operations). I didn't understand all 
of your suggestions, eg: why the Evaluator should do assignments when not all 
ELs support assignments, or the reference to javax.el. Plus, as you mention, 
there are backwards compatibility issues and the suggested changes can only be 
completed in the next major release. I'm marking as a WON'T FIX. Feel free to 
propose a patch so we can constrast the current Evaluator API bits and the ones 
you are proposing (and reopen).


> Refactoring of Evaluator.execLocation
> -
>
> Key: SCXML-18
> URL: http://issues.apache.org/jira/browse/SCXML-18
> Project: Commons SCXML
>  Issue Type: Wish
>Affects Versions: 0.5
>Reporter: Tuomas Kiviaho
>
> There is a special case public method having return value tied to be a Node 
> from DOM API in the Evaluator api used only by 'assign' location.
> Implementing the execLocation requires use of Node adapters when the 
> expression doesn't evaluate to Node. Knowledge how the DOM api is used is 
> required to reduce the amount of work put adapter implementation.
> Suggestions:
> 1. Declare new method to evaluator that handles assigment and deprecate 
> execLocation.
> 2. Implement evaluator expressions that can both resolve or assignment of 
> values.
> 3. Use some language neutral and already existing evaluator api that suits 
> the needs but doesn't exceed them either to keep things simple when the spec 
> is finalized and backport the current evaluator framework to it for backwards 
> compatibility. My current suggestion is javax.el

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-18) Refactoring of Evaluator.execLocation

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-18?page=all ]

Rahul Akolkar updated SCXML-18:
---

Affects Version/s: 0.5
   (was: 0.6)

I think the "Affects Version" field should point to released version(s).


> Refactoring of Evaluator.execLocation
> -
>
> Key: SCXML-18
> URL: http://issues.apache.org/jira/browse/SCXML-18
> Project: Commons SCXML
>  Issue Type: Wish
>Affects Versions: 0.5
>Reporter: Tuomas Kiviaho
>
> There is a special case public method having return value tied to be a Node 
> from DOM API in the Evaluator api used only by 'assign' location.
> Implementing the execLocation requires use of Node adapters when the 
> expression doesn't evaluate to Node. Knowledge how the DOM api is used is 
> required to reduce the amount of work put adapter implementation.
> Suggestions:
> 1. Declare new method to evaluator that handles assigment and deprecate 
> execLocation.
> 2. Implement evaluator expressions that can both resolve or assignment of 
> values.
> 3. Use some language neutral and already existing evaluator api that suits 
> the needs but doesn't exceed them either to keep things simple when the spec 
> is finalized and backport the current evaluator framework to it for backwards 
> compatibility. My current suggestion is javax.el

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-17) Unified EL support

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-17?page=all ]

Rahul Akolkar updated SCXML-17:
---

Fix Version/s: 1.0
Affects Version/s: 0.5
   (was: 0.6)

Indeed, the ability to plug in the unified EL API (and expressions thereof) in 
[scxml] is a desired feature. I'm marking this against 1.0, but if an 
appropriate patch were to become available, it could be sooner.


> Unified EL support
> --
>
> Key: SCXML-17
> URL: http://issues.apache.org/jira/browse/SCXML-17
> Project: Commons SCXML
>  Issue Type: Wish
>Affects Versions: 0.5
> Environment: jdk 5.0
>Reporter: Tuomas Kiviaho
> Fix For: 1.0
>
>
> Currently there are dependencies to both JSF 1.1 and servlet api. Both of 
> them have different EL apis, but the latter is only currently supported while 
> the former has couple of patches to get parts of it working. Support for new 
> javax.el API would be more than welcome because it would not only support JSF 
> out-of-the-box but replace compile time dependencies with one (container) 
> provided api that supports pointers as well as values.
> The API is available at least at java.net repository 
>  along with RI.
>   
>   com.sun.el
>   el-ri
>   1.0
>   
>   
>   javax.faces
>   jsf-api
>   1.2
>   

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-13) [jexl] Make JEXL allow for an Uberspect plugin

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-13?page=all ]

Rahul Akolkar updated JEXL-13:
--

  Bugzilla Id:   (was: 38320)
Fix Version/s: 2.0

Updating fix version per last comment.


> [jexl] Make JEXL allow for an Uberspect plugin
> --
>
> Key: JEXL-13
> URL: http://issues.apache.org/jira/browse/JEXL-13
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.0
> Environment: Operating System: All
> Platform: All
>Reporter: Doug Rand
>Priority: Minor
> Fix For: 2.0
>
> Attachments: jexl-patch.txt, patch.txt
>
>
> Unlike Velocity, JEXL does not allow for the Uberspect object to be replaced 
> at
> runtime. By allowing replacement JEXL can be extended for Java 1.5 or other
> desireable functionality. I have a patch available for this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-3) [JEXL] Static method resolution and changes to context

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-3?page=all ]

Rahul Akolkar updated JEXL-3:
-

  Bugzilla Id:   (was: 39193)
Fix Version/s: 2.0

I agree that the VariableResolver style API is much better than get/set vars. 
This has to be moved to a major release (if this change is to be made). 
Therefore, updating fix version to 2.0.


> [JEXL] Static method resolution and changes to context
> --
>
> Key: JEXL-3
> URL: http://issues.apache.org/jira/browse/JEXL-3
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: dion gillard
> Fix For: 2.0
>
> Attachments: jexl-patch.zip
>
>
> From: Guido Anzuoni <[EMAIL PROTECTED]>
> Here I will try to explain may changes to see if you agree to include in the 
> trunk.
> 1. UberspectImpl
> I need to include static methods resolution in expressions (e.g.
> System.currentTimeMillis()). I patched the class to allow it.
> 2. JexlContext
> Resolving vars using a Map is not enough flexible for my needs. I have 
> modified
> it to have a single method
> public Object resolveVariable(String var);
> This allows me for better flexibility in the resolution process.
> I have implemented a JextContext based on a java.util.Map, an extensible
> JexlContext and a delegating JexlContext.
> The extensible resolver is abstract and has a "parent" context to which
> delegates in the case local resolution failes.
> Delegating implementation extends the extensible context and uses another
> JexlContext for local resolution.
> More, I have removed any reference to JexlContex.getVars() in the code.
> If you wish I can send the modified classes to better evaluate my changes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-10) [jexl] Make possible checking for unresolved variables

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-10?page=all ]

Rahul Akolkar updated JEXL-10:
--

  Bugzilla Id:   (was: 31188)
Fix Version/s: 2.0

Update fix version per earlier comment.


> [jexl] Make possible checking for unresolved variables
> --
>
> Key: JEXL-10
> URL: http://issues.apache.org/jira/browse/JEXL-10
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: Paul Libbrecht
>Priority: Minor
> Fix For: 2.0
>
>
> Currently jexl is quite tolerant with undefined variable...
> I think it would make sense to allow a switch that would throw an exception 
> everytime a variable is 
> requested but not defined.
> This seems to be what was done at:
>  http://nagoya.apache.org/eyebrowse/ReadMsg?listName=commons-
> [EMAIL PROTECTED]&msgId=1231239
> I haven't checked how the patch can apply... but I think it's an important 
> feature.
> paul

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-11) [jexl] Don't make null convertible into anything

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-11?page=all ]

Rahul Akolkar updated JEXL-11:
--

  Bugzilla Id:   (was: 31189)
Fix Version/s: 2.0

Update fix version per earlier comment.


> [jexl] Don't make null convertible into anything
> 
>
> Key: JEXL-11
> URL: http://issues.apache.org/jira/browse/JEXL-11
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.0
> Environment: Operating System: other
> Platform: Other
>Reporter: Paul Libbrecht
>Priority: Minor
> Fix For: 2.0
>
>
> Currently JEXL is very tolerant with null (and unresolved variables)... 
> I am unsure now but I think null will become false if the output of a test, 
> null will become the empty 
> string if concatenated to a string, null will become the number zero when 
> added. Moreover, 
> invoking a method on null gives you... null...
> I would love a switch that just disables all this (I think this would impact 
> quite a lot) allowing my jexl 
> snippets to be quite more predictable!
> paul

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-15) [jexl] Needs definable functions

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-15?page=all ]

Rahul Akolkar updated JEXL-15:
--

  Bugzilla Id:   (was: 31186)
Fix Version/s: 2.0

Update fix version per earlier comment.


> [jexl] Needs definable functions
> 
>
> Key: JEXL-15
> URL: http://issues.apache.org/jira/browse/JEXL-15
> Project: Commons JEXL
>  Issue Type: Improvement
> Environment: Operating System: other
> Platform: Other
>Reporter: Paul Libbrecht
>Priority: Minor
> Fix For: 2.0
>
>
> Currently, in Jexl, the only way to add a functionality is to define a 
> variable.
> Typically this is done in a separate environment... e.g. in jelly's j:new, 
> j:set or...
> Using this, one can define, say, "a" then invoke "a.doSomething(withThat)".
> It would be nice to allow adding methods, e.g. "doSomething" to be invoked 
> without any object.
> This way I could just say "doSomething".
> Examples of usage include:
> - add some mathematical functions to make jexl full featured mathematically 
> (e.g. "abs", "exp", 
> "atan")
> - add some "general purpose utilitites" (e.g. "tokenize(aString)", 
> "toString(xx)", or 
> "relativeUrl(baseUrl, relPath)")
> - thereby become more compatible with JSP (i've been told)
> This should promote general usage of such functions availability.
> In some situations this would help a lot. For example in maven where I too 
> often still see 
> srcFile="${baseDIr+pathToResource}" which prevents any overridability.
> (e.g. the cvs-usage.xml page in the xdoc plugin)
> paul

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-16) allowing quote escaping

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-16?page=all ]

Rahul Akolkar updated JEXL-16:
--

Fix Version/s: 2.0
Affects Version/s: 1.0

Any grammar changes will not happen before 2.0, updating fix version.


> allowing quote escaping
> ---
>
> Key: JEXL-16
> URL: http://issues.apache.org/jira/browse/JEXL-16
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.0
> Environment: windows/linux using commons-jexl from commons-scxml
>Reporter: Nestor Urquiza
> Fix For: 2.0
>
>
> There is a need for jexl to support escaping since otherwise you cannot use 
> the apostrophe within a string like in 
> "I'm just trying to use apostrophe as punctuation mark" 
> which right now fails while using jexl .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (JEXL-7) [jexl] Unable to reference statics

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-7?page=all ]

Rahul Akolkar resolved JEXL-7.
--

Resolution: Fixed

> [jexl] Unable to reference statics
> --
>
> Key: JEXL-7
> URL: http://issues.apache.org/jira/browse/JEXL-7
> Project: Commons JEXL
>  Issue Type: Bug
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Sean Ferguson
> Fix For: 1.1
>
>
> When using Jexl, I am unable to reference anything static.  That includes for
> example Character.isLowerCase() or anything else that is static.  Even if I 
> get
> a reference to the class, it cannot reference the static methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Reopened: (JEXL-7) [jexl] Unable to reference statics

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-7?page=all ]

Rahul Akolkar reopened JEXL-7:
--

 
Re-opening, to resolve correctly.


> [jexl] Unable to reference statics
> --
>
> Key: JEXL-7
> URL: http://issues.apache.org/jira/browse/JEXL-7
> Project: Commons JEXL
>  Issue Type: Bug
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Sean Ferguson
> Fix For: 1.1
>
>
> When using Jexl, I am unable to reference anything static.  That includes for
> example Character.isLowerCase() or anything else that is static.  Even if I 
> get
> a reference to the class, it cannot reference the static methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-7) [jexl] Unable to reference statics

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-7?page=all ]

Rahul Akolkar updated JEXL-7:
-

  Bugzilla Id:   (was: 22193)
Fix Version/s: 1.1
Affects Version/s: (was: Nightly Builds)

> [jexl] Unable to reference statics
> --
>
> Key: JEXL-7
> URL: http://issues.apache.org/jira/browse/JEXL-7
> Project: Commons JEXL
>  Issue Type: Bug
> Environment: Operating System: Windows XP
> Platform: PC
>Reporter: Sean Ferguson
> Fix For: 1.1
>
>
> When using Jexl, I am unable to reference anything static.  That includes for
> example Character.isLowerCase() or anything else that is static.  Even if I 
> get
> a reference to the class, it cannot reference the static methods.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-12) [JEXL] Implement short-circuit boolean evaluation

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-12?page=all ]

Rahul Akolkar updated JEXL-12:
--

  Bugzilla Id:   (was: 29550)
Fix Version/s: 1.0
Affects Version/s: (was: Nightly Builds)

> [JEXL] Implement short-circuit boolean evaluation
> -
>
> Key: JEXL-12
> URL: http://issues.apache.org/jira/browse/JEXL-12
> Project: Commons JEXL
>  Issue Type: Improvement
> Environment: Operating System: All
> Platform: All
>Reporter: Matthew Firth
>Priority: Minor
> Fix For: 1.0
>
> Attachments: short-circuit-eval.patch
>
>
> The current implementation of ASTAndNode and ASTOrNode will evaluation both 
> sides of an expression before returning a result.  I think most developers 
> these days seem to expect the RHS of an AND/OR expression to be ignored if 
> the 
> LHS is sufficient to determine the result 
> (e.g. if A=>true, "A or B"=>true, regardless of B).
> The patches appear to be trivial - if a committer is interested & thinks it 
> worthwhile I'll create them.
> (btw, the old Turbo Pascal compiler described this optimisation as "short 
> circuit boolean evaluation"; I'm not sure if that is a common name for it.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (JEXL-17) ExpressionFactory.createNewExpression should throw an Exception in case of a parsing error, not Error

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/JEXL-17?page=all ]

Rahul Akolkar updated JEXL-17:
--

Fix Version/s: 1.1
Affects Version/s: 1.0
   (was: Nightly Builds)

> ExpressionFactory.createNewExpression should throw an Exception in case of a 
> parsing error, not Error
> -
>
> Key: JEXL-17
> URL: http://issues.apache.org/jira/browse/JEXL-17
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 1.0
>Reporter: Kohsuke Kawaguchi
> Fix For: 1.1
>
> Attachments: JEXL-17.diff
>
>
> When ExpressionFactory.createNewExpression(...) takes an syntactically 
> incorrect expression, JEXL throws TokenMgrError. However, typical callers 
> (such as Jelly) don't expect such syntax error to be a java.lang.Error, so it 
> fails to catch it.
> A typical outcome is therefore the thread to die completely, and even worse 
> the stack trace doesn't report neither what was the expression that was being 
> parsed, nor does it report any contextual information (again in case of 
> Jelly, that would be where in the jelly script this error happened.)
> This makes the error diagnosis unnecessarily hard. I believe the proper thing 
> to do is to wrap such an exception into java.lang.Exception or its sub-class, 
> allowing the caller to catch it.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (SCXML-15) User of SCXMLExecutor does not have access to the current context data

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-15?page=all ]

Rahul Akolkar resolved SCXML-15.


Resolution: Won't Fix

Yes, that would be another option, should have been option (e) in my last 
comment. Thanks for the clarification, I'm accordingly resolving without making 
any changes.


> User of SCXMLExecutor does not have access to the current context data
> --
>
> Key: SCXML-15
> URL: http://issues.apache.org/jira/browse/SCXML-15
> Project: Commons SCXML
>  Issue Type: Improvement
> Environment: Windows, JDK 1.4.2
>Reporter: Sitthichai Rernglertpricha
> Assigned To: Rahul Akolkar
>Priority: Minor
> Fix For: 0.6
>
>
> Currently, SCXMLExecutor does not provide method for client to get local 
> variables associated with the Context of the current state. 
> All created Context are maintained in the SCInstance object within the 
> SCXMLExecutor class, and currently the getSCInstance() of SCXMLExecutor does 
> not have any protected or public qualifier. Hence getSCInstance() cannot only 
> be accessed by SCXMLExecutor or classes within the org.apache.commons.scxml 
> package. Can we change getSCInstance() method to be protected or public ? 
> This allows the client to call getSCInstance().getContext() to return the 
> Context associated with the current state or create a child class of 
> SCXMLExecutor that return variables associated with the current context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-16) The 'target' of a cannot be a data element name

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-16?page=all ]

Rahul Akolkar updated SCXML-16:
---

Fix Version/s: 0.6
 Assignee: Rahul Akolkar

Correct. Also, targettype and sendid should be evaluated as well, in line with 
the latest Working Draft. If you want, you can update your patch to include 
those as well. I'll get to this in a couple of days.


> The 'target' of a  cannot be a data element name
> --
>
> Key: SCXML-16
> URL: http://issues.apache.org/jira/browse/SCXML-16
> Project: Commons SCXML
>  Issue Type: Bug
> Environment: Windows, JDK 1.4.2
>Reporter: Sitthichai Rernglertpricha
> Assigned To: Rahul Akolkar
>Priority: Minor
> Fix For: 0.6
>
> Attachments: patch-send.txt
>
>
> Based on the SCXML specification, the 'target' attribute of a  element 
> can be "expression returning a unique identifier of the event target".
> The specification also shows an example that reads the target from a data 
> element within .
> The current SCXML runtime treats target as a literal string and does not 
> "evaluate" it.
> The attached patch file shows a way to "evalulate" the target before calling 
> the EventDispatcher#send method, and support specifying the target by a data 
> element. Enclosing target within single-quote will prevent evaluation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (SCXML-15) User of SCXMLExecutor does not have access to the current context data

[Rahul Akolkar (JIRA)]

 [ http://issues.apache.org/jira/browse/SCXML-15?page=all ]

Rahul Akolkar updated SCXML-15:
---

Fix Version/s: 0.6

> User of SCXMLExecutor does not have access to the current context data
> --
>
> Key: SCXML-15
> URL: http://issues.apache.org/jira/browse/SCXML-15
> Project: Commons SCXML
>  Issue Type: Improvement
> Environment: Windows, JDK 1.4.2
>Reporter: Sitthichai Rernglertpricha
> Assigned To: Rahul Akolkar
>Priority: Minor
> Fix For: 0.6
>
>
> Currently, SCXMLExecutor does not provide method for client to get local 
> variables associated with the Context of the current state. 
> All created Context are maintained in the SCInstance object within the 
> SCXMLExecutor class, and currently the getSCInstance() of SCXMLExecutor does 
> not have any protected or public qualifier. Hence getSCInstance() cannot only 
> be accessed by SCXMLExecutor or classes within the org.apache.commons.scxml 
> package. Can we change getSCInstance() method to be protected or public ? 
> This allows the client to call getSCInstance().getContext() to return the 
> Context associated with the current state or create a child class of 
> SCXMLExecutor that return variables associated with the current context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (SCXML-15) User of SCXMLExecutor does not have access to the current context data

[Rahul Akolkar (JIRA)]

[ 
http://issues.apache.org/jira/browse/SCXML-15?page=comments#action_12426373 ] 

Rahul Akolkar commented on SCXML-15:


Do any of the following avenues work? If not, please post your usecase to help 
us better understand the need for this improvement request.

Generally speaking, "communication" between the state machine and its 
environment is best achieved via the root context on the executor. One can 
avail of:

a) "Read access" on the root context
b) Datamodel child of root  element (also available via root context)

Similarly, SCXML provides mechanisms for "exporting" values in the current 
Context to external processes, namely via:

c) Passing the EventDispatcher a namelist onsend()
d) Passing an invoked process s

The "constrained" access as of now is actually much beneficial from a modeling 
and tooling perspective since it offers well-defined hooks to work with.

Leaving this issue open for now.


> User of SCXMLExecutor does not have access to the current context data
> --
>
> Key: SCXML-15
> URL: http://issues.apache.org/jira/browse/SCXML-15
> Project: Commons SCXML
>  Issue Type: Improvement
> Environment: Windows, JDK 1.4.2
>Reporter: Sitthichai Rernglertpricha
> Assigned To: Rahul Akolkar
>Priority: Minor
> Fix For: 0.6
>
>
> Currently, SCXMLExecutor does not provide method for client to get local 
> variables associated with the Context of the current state. 
> All created Context are maintained in the SCInstance object within the 
> SCXMLExecutor class, and currently the getSCInstance() of SCXMLExecutor does 
> not have any protected or public qualifier. Hence getSCInstance() cannot only 
> be accessed by SCXMLExecutor or classes within the org.apache.commons.scxml 
> package. Can we change getSCInstance() method to be protected or public ? 
> This allows the client to call getSCInstance().getContext() to return the 
> Context associated with the current state or create a child class of 
> SCXMLExecutor that return variables associated with the current context.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]