Reordering mappings from domain in xml resulting in StackOverflowException
--------------------------------------------------------------------------
Key: CAY-743
URL: https://issues.apache.org/cayenne/browse/CAY-743
Project: Cayenne
Issue Type: Bug
Components: Cayenne Core Library
Affects Versions: 1.2 [STABLE]
Environment: 64 bit architecture (Core2 duo), Java 1.6, Tomcat 5.5.20
Reporter: Marius Siegas
Application worked fine on another server with similar software, but after
moving it to the new server...
First we've encountered StackOverflowException which should better throw an
exception of something not being found (there's a comment about an infinite
loop, so it's a known problem).
We've made a nasty fix for that to see what's missing and found that class in
one .map.xml references class in another .map.xml, but the latter not being
loaded before the former (although in the xml they're specified in a correct
order) configuration fails.
TO THE POINT
In the source file ConfigLoader.java I've found the root problem for this.
DomainHandler there uses a HashMap for map locations. When loading the xml it
adds mappings to that HashMap and after that it iterates over the map, loading
mappings in the order they're in the map (not the order they're in the xml) and
that became a problem in our new server (HashMap: This class makes no
guarantees as to the order of the map).
I've fixed it by changing line:
mapLocations = new HashMap();
into something like this:
mapLocations = new ArrayMap();
(Note, that the ArrayMap is made by me and based on ArrayList so the order of
its entries doesn't change, it may not be very efficient, but for a few
mappings in our projects it doesn't matter, because we have at most 3 in one
domain)
I think this may even be a more architectural problem, so I'm not sure if my
fix is any good but it sure fixed our application's behaviour (no more
StackOverflowException's or anything)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.