Well, as often happens, boiling it down to a minimal test case uncovered
the problem. I had an old version of my model.jar (the jar being built)
in my ant/lib directory. Dunno why... it had been there for six months.
Apparently cgen was loading classes from the old jar. The class that
started the problem was a recent addition that wasn't in the old jar,
hence the ClassNotFoundException.
I rechecked the versions; this happens only with M9 (not M8 as I said
below). Maybe this will indicate some small vulnerability that was
introduced with M9, or maybe it'll only be a useful example in case
someone else runs into this. Perhaps I have to be more careful in
specifying the classpath with the new cgen? What's the preferred
practice for where to put cayenne.jar? I've been copying it into my
ant/lib and not specifying a classpath.
Thanks.
Mike Kienenberger wrote:
>That means it's a probably due to a change in a supporting class like
>EntityResolver rather than in cgen.
>
>You could probably help Andrus by testing with both M8 and M9 (it
>sounds like you might have already done this) so he knows when the
>problem occurred. It'd probably be helpful at this point to also open
>a JIRA issue and attach minimalistic example code demonstrating the
>problem.
>
>Unfortunately, I haven't gotten around to upgrading to the new Cayenne
>reorganization, so I'm still a few milestones behind.
>
>On 1/2/06, Bryan Lewis <brya..aine.rr.com> wrote:
>
>
>>Okay, I tried 1.2M5 and M7. No problems. The strangeness is only with M8.
>>
>>
>>Mike Kienenberger wrote:
>>
>>
>>
>>>Any chance you could try this with M5 and M7? It should be a matter
>>>of pointing your cgen taskdef to the alternate jar file.
>>>
>>>I made changes to cgen on M5 and M7, and I'd like to narrow it down a bit.
>>>M5 had the majority of the changes, and M7 had one minor change to the
>>>Velocity engine instantiantion.
>>>
>>>If it's broke after M7, then it's probably due to a change outside of
>>>the cgen code, and Andrus will have to investigate.
>>>
>>>On 1/2/06, Bryan Lewis <brya..aine.rr.com> wrote:
>>>
>>>
>>>
>>>
>>>>I'm trying 1.2-M9 and the cgen task is acting strangely. The generation
>>>>works as usual for the first seven entities (out of 214), but on the eighth
>>>>it runs into a problem. I added some print statements to the source and
>>>>narrowed it down a bit.
>>>>
>>>>EntityResolver.constructCache() calls ObjectEntity.getJavaClass() on my
>>>>entity model.AutoUpdate.
>>>>(It's a small class, nothing special about it that I can see, only one
>>>>method.)
>>>>It calls Util.getJavaClass(name) which gets
>>>>"java.lang.ClassNotFoundException: model.AutoUpdate".
>>>>
>>>>The task continues, however, and 17 entities later it stops in almost the
>>>>same place, Util.getJavaClass() calling Class.forName(). It gives an error
>>>>message "Error generating classes: common/ExceptionAdapter" which is strange
>>>>because that's a small utility class in a different package that happens to
>>>>be imported by the entity.
>>>>
>>>>I read the new docs and saw new options for cgen, but they're optional and
>>>>I didn't think they'd break the way I was using it. Which is:
>>>>
>>>> <target name="cgen">
>>>> <taskdef name="cgen"
>>>>classname="org.objectstyle.cayenne.tools.CayenneGenerator"/
>>>> <cgen map="conf/DataMap.map.xml"
>>>> destDir="src"
>>>> template="conf/subclass.vm"
>>>> supertemplate="conf/superclass.vm"
>>>> superpkg="model.auto"
>>>> usepkgpath="true"
>>>> />
>>>> </target>
>>>>
>>>>I've reduced my model to only two entities, trying to make a simple test
>>>>case, and the problem is still happening. I tried removing my two template
>>>>lines, no diff. This worked fine in 1.2M4.
>>>>
>>>>
>>>>
>>>>
>
>
>
This archive was generated by hypermail 2.0.0 : Mon Jan 02 2006 - 15:22:26 EST