This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 155083 - Unexpected IllegalArgumentException: old node must be in the tree
Summary: Unexpected IllegalArgumentException: old node must be in the tree
Status: NEW
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL Mapper (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Sergey Lunegov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-09 22:01 UTC by Nikita Krjukov
Modified: 2011-11-30 16:21 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
The test BPEL project (10.44 KB, application/x-compressed)
2008-12-09 22:06 UTC, Nikita Krjukov
Details
Exception stack trace (4.00 KB, text/plain)
2008-12-09 22:08 UTC, Nikita Krjukov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nikita Krjukov 2008-12-09 22:01:41 UTC
The exception appears quite frequently while editing expressions in BPEL mapper. 

It appears almost each time the Mapper tries regenerating an XPath expression and put it to BPEL. 
An obligatory condition - the expression must have related extensions: TypeCast, PseudoComp or Predicate. 

The exception appears when at list an extension is deleted (method LsmProcessor.deleteAllLsm(from))

The latest (with number more then #1887) soa-dev build are required to reproduce the issue 
http://beryl.russia.sun.com:8080/hudson/job/sierra/

Step to reproduce: 
-- Download JCAPS version of NetBeans from soa-dev branch (see above)
-- Open attached project
-- Open newProcess1.bpel
-- Go to the Design view 
-- Double click on Assign2 (it is the only assign in the process)
-- You will see the BPEL mapper with single assignment. It contains Concat function. 
-- Add a new link from left tree (from anything) to concat. 
-- Now you will see blinking error sign in the right bottom corner of the NetBeans.
Comment 1 Nikita Krjukov 2008-12-09 22:06:57 UTC
Created attachment 74765 [details]
The test BPEL project
Comment 2 Nikita Krjukov 2008-12-09 22:08:52 UTC
Created attachment 74767 [details]
Exception stack trace
Comment 3 Nikita Krjukov 2008-12-09 22:09:39 UTC
I found another similar issue #150906
Comment 4 Sergey Lunegov 2008-12-10 15:20:32 UTC
Related to GF ESB distribution. Not to NB 7.0
Comment 5 Marian Mirilovic 2009-02-20 18:08:15 UTC
update no67 keyword
Comment 6 Nikita Krjukov 2009-04-14 21:58:48 UTC
I reduced the priority because a workaround has already applied, which prevents appearance of the Exception at all. 
Comment 7 Nikita Krjukov 2009-04-14 22:21:33 UTC
An additional investigation required to understand what was the initial reason of the exception. 
The workaround code is located at the BpelMapperUpdater:327 and :354. It can be rolled back to reproduce the exception
again. 

I tried analyzing again but failed. But I'd like to put some notes, which should be helpful next time: 

1. It seems the BPEL model's transaction doesn't support rollback. It looks like if an exception happens somewhere in
middle of transaction, then the model can come to an inconsistent state. It can be an indirect reason of BPEL model's
vulnerability. 

2. Once the exception happened it is necessary to close editor and reopen it again to start next iteration. It because
the BPEL model becomes corrupted such way that Undo works wrong. Undo adds a new Editor children to the From component. 
So the model becomes inconsistent with sources. The BPEL sources doesn't contain an editor in from at all, but BPEL
model can contain multiple editor components at corresponding place. 

3. I think the good idea is to use JUnit tests (at BPEL model) to solve this puzzle. The tests can call methods
separately. It's helpful to locate harmful place in code.