[MAGNOLIA-1131] [wf] NPE generated for some reason from workflow. Created: 11/Oct/06  Updated: 23/Jan/13  Resolved: 23/Feb/07

Status: Closed
Project: Magnolia
Component/s: workflow
Affects Version/s: None
Fix Version/s: 3.0.2, 3.1 M1

Type: Bug Priority: Minor
Reporter: Chris Miner Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: XML File expression.xml     Text File stacktrace.txt     Text File stacktrace.txt     Text File stacktrace.txt    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Comments   
Comment by Chris Miner [ 11/Oct/06 ]

Here's the stack traces produced on start up of magnolia.

Comment by Chris Miner [ 11/Oct/06 ]

I looked into this a little and found that the immediate cause is that a flowexpression doesn't have an expression class. That is to say that in the JCRExpressionStore.fetchNext() method, the FlowExpression fe returns null if you call:
fe.getExpressionClass()

this causes the subsequent call to
ExpoolUtils.isAssignableFromClass(fe, this.assignClass)

to fail. The flow expression in question at the time is an XMLRawExpression if that means anything.

Comment by John Mettraux [ 13/Oct/06 ]

Just noticed that issue now... Gmail truncates the email titles...

Opened a bug report for it :
http://sourceforge.net/tracker/index.php?func=detail&aid=1576372&group_id=54621&atid=474244
(as I'll maybe fix that from OpenWFE).

stay tuned.

Comment by John Mettraux [ 13/Oct/06 ]

Could the stack trace be expanded with some openwfe.org.* debug info ? Like the 50 lines just before the NPE ?

Thanks in advance,

John

Comment by John Mettraux [ 13/Oct/06 ]

corrupted flow left behind ?

Comment by Chris Miner [ 13/Oct/06 ]

I added a new log file attachment. Not sure how to know if it is a corrupted flow left behind. Would an export of my expressions or store repositories help?

Comment by Chris Miner [ 13/Oct/06 ]

A better stack trace with less bean logging.

Comment by John Mettraux [ 14/Oct/06 ]

BTW, I should have asked that first, but how did you get into that situation ? Are there steps to reproduce that ?

Comment by Chris Miner [ 15/Oct/06 ]

At this point I don't have steps to reproduce the problem. I've been working on some functionality based on workflow. So by now I have executed various workflows numerous times, with various versions of Magnolia check out almost daily from the HEAD, and some where along the line I started getting these stack traces shortly after startup.

After startup the scheduler runs, looking for scheduled items. Eventually ExpoolUtils.isAssignableFromClass(FlowExpression, Class) fails because the flow express is a RawExpression that doesn't have an expression class. The raw expression's xmlBranch is an org.jdom.Element with the name "collect-data", which is the name of a subprocess in my workflow definition.

Comment by John Mettraux [ 16/Oct/06 ]

This issue should then be closed : you seem to have refined it into MGNL-1144.

Comment by Chris Miner [ 16/Oct/06 ]

No that is a different problem that I stumbled onto when I enabled debugging output while looking at this problem. And after I added code that kept this problem from popping up. For the puposes of debugging I changed the code in fetchNext from:

if ( ! ExpoolUtils.isAssignableFromClass(fe, this.assignClass))

{ return fetchNext(); }

to

if((fe instanceof RawExpression) && (fe.getExpressionClass() == null)) {
log.debug("No expression class for fe: "+fe.getId());
log.debug("No expression class for fe with xmlBranch: "+((RawExpression) fe).getDefinitionName());
}
else if ( ! ExpoolUtils.isAssignableFromClass(fe, this.assignClass)) {
return fetchNext();
}

Maybe this alters the flow in a way that makes no sense. However, I think we can safely assume that fetchNext evenutally returns null.

Comment by Chris Miner [ 16/Oct/06 ]

example expression that leads to error.

Comment by Chris Miner [ 16/Oct/06 ]

I attached the xml of a problematic flow expression, and think the problem has to do with the first field defined:
<field name="xmlBranch">
<raw-xml>
<invent-concept/>
</raw-xml>
</field>

Perhaps the real bug is that one is allowed to lauch workflows that are invalid. Or that invalid workflows lead to invalid expressions that lead to problems with the scheduler?

Comment by Magnolia International [ 29/Jan/07 ]

John, was this fixed in openwfe? I see the sf.net issue was closed... however, it seems I still get this with 1.7.2 - I haven't investigated much, though, so I have no clue why/when this pops up, other than it's happening when the "redeschule" is triggered.

Comment by John Mettraux [ 29/Jan/07 ]

Hi,

if I trust the latest stack trace, the NPE appears in JCRExpressionStore which is not in OpenWFE but in Magnolia.

Best regards,

John

Comment by Magnolia International [ 29/Jan/07 ]

woops.. true.
Looking at the code, the only explanation I see would be that line 92 of ExpoolUtils
((RawExpression)fe).getExpressionClass()
returns null. Any idea why that would be the case?

Comment by John Mettraux [ 29/Jan/07 ]

Hi Greg,

it means that this RawExpression doesn't map to any OpenWFE expression class.

In that flow segment :

<sequence>
<participant ref="a" />
</sequence>

two expression appear, sequence and participant, they are managed respectively by SequenceExpression and ParticipantExpression.

A RawExpression instance contains the not yet interpreted XML (XmlRawExpression) of a flow segment. getExpressionClass() takes the name of the XML root element and attempts to retrieve the corresponding FlowExpression implementation class via the expressionMap but the name doesn't seem to be mapped to anything and null is returned.

Would be good to know what name gets looked up, you could look at the faulty RawExpression's XML segment.

John

Comment by Chris Miner [ 29/Jan/07 ]

Hi Greg and John,

It means that the xml definition of the workflow is probably invalid.

I caused my problem by trying to call a subprocess (invent-concept) outside of a sequence. I had XML such as <invent-concept/> directly under the process-definition node. That may or may not be acceptable in workflow definition, but at run time in magnolia it just doesn't work.

That xml unpacks into a piece of an expression tree that is represented as an XmlBranch and contains the raw xml.

One could look at the faulty RawExpressions XML segement and then fix the problem in the original xml. However one can only fix the problem in a running system by deleting the expression from the expressions workspace. I think such an un executable expression 'tree' keeps workflow in general from functioning. So probably you want to delete all the expressions from the expressions workspace that have this problem and then try again with your modified workflow definition.

Comment by John Mettraux [ 29/Jan/07 ]

Hi Chris !

Greg, I then think you can safely skip the RawExpression with no corresponding expression class (in fact the corresponding expression class is thus "SubProcessRefExpression").

Either skip or replace the null with SubProcessRefExpression.class

Thanks guys, cheers,

John

Comment by Magnolia International [ 01/Feb/07 ]

Chris,

> It means that the xml definition of the workflow is probably invalid.
In my case it seems valid: it's just a simple called to a subprocess in the form of <sub-process-name/>

John,

> I then think you can safely skip the RawExpression with no corresponding expression class
> (in fact the corresponding expression class is thus "SubProcessRefExpression").
> Either skip or replace the null with SubProcessRefExpression.class

How can we be sure its a valid sub-process reference?
Is this generic enough that it should be fixed in ExpoolUtils ? (and in the meantime, Ill use a local copy of the method in the StoreIterator with a todo until next openwfe release?)

Comment by Magnolia International [ 01/Feb/07 ]

Ha, some more details about my situation: this raw expression refers a subprocess defined in a library. As a first reschedule() is executed before any workflow is launched (or proceeded I assume), the library not being loaded, that subprocess is not yet referenced in the ExpressionMap and thus the ExpoolUtils method fails. Should I force library loading on startup, or should I just skip the unknown elements, hoping that (in this case) they're not Schedulables ?

Comment by Magnolia International [ 01/Feb/07 ]

Guys,

I just commited a fix for this in branch/magnolia-module-workflow-deferred-storage

Chris, do you think you could have a look at this, see if it fixes your problems in a satisfying way? (i.e. all it does is just log a warning ...)
(mind that this branch as deferred expressions storage as per MAGNOLIA-1322)

If it's fine, then we could potentially include this in 3.0.2

Comment by Magnolia International [ 01/Feb/07 ]

Marking this for 3.0.2 and 3.1 in the event the fix is validated by John & Chris.

Comment by Magnolia International [ 22/Feb/07 ]

Any comment/feedback before I merge this to the 3.0 branch and the trunk ?

Comment by Magnolia International [ 23/Feb/07 ]

commited to branches/magnolia-3.0 and trunk

Generated at Mon Feb 12 03:23:57 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.