CDV ❯ tim loading fails sliently
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
-
-
hhuynh
-
Reporter: tgautier
-
March 27, 2008
-
0
-
Watchers: 1
-
April 25, 2008
-
April 03, 2008
Description
Tried to build a tim using ant. I probably got a lot of things wrong - the filename, the osgi meta data. All I ever got was a message that the tim wasn’t found in the repos specified.
We have to be more verbose when we cannot find something. I want to know where we looked. If we looked at a file, log it. If we opened that file and examined its metadata and rejected it, log it.
Getting all the metadata for tims is rather hard (when you don’t use the maven archetype) so we need to be better about reporting what failed.
Comments
Tim Eck 2008-03-27
Alex Miller 2008-03-27
We’ve made several attempts at this. It may just be that it’s not getting printed at the right log level or something. Both Juris and I have tried to make this better. I’ve written logging stuff in the past to print copious information about exactly this problem in fact.
The problem with printing “where we looked” is that at least in the past we were sometimes examining hundreds or 1000s of jars and you don’t know till the end whether you’ve succeeded or not. I think we’ve changed now to where we are looking at a much more targeted set of jars so that may not be as much of an issue. We probably need some kind of an analysis switch too that can be more verbose.
Part of the problem in the code is that it’s done in several passes and each pass doesn’t really know whether it’s “failure” is a problem till later passes have run. I think there is probably some refactoring that must occur to make this better. But we should do that.
Tim Eck 2008-03-27
sounds good. The only “hard” issues (ie. had to use a debugger on the ModuleLoader code) I’ve had have been with rejections that happen *after* a jar is already found, not with the logic of locating the module jar
Fiona OShea 2008-03-28
Taylor to add comment
Taylor Gautier 2008-03-28
btw, just to let you guys know - I have seen that the error reporting is much better, and have run into cases where the product just told me what was wrong, I fixed it and went on my merry way. This was excellent.
Just happened to run into some other cases listed in this bug where it didn’t happen, so hoping we can catch more.
Alex Miller 2008-04-01
Juris, please assess….
Juris Galang 2008-04-02
The problem was that the TIM jar file was incorrectly named. It was using dot instead of dash to separate the version qualifier from the numnber.
TC client had an error messaage, listing the list of repositories where it looked, what the groupId, version, and name of the missing TIM — it would help if it also listed the expected JAR file name instead of assuming that the user understands how to construct the filenames for JARs.
For reference, we have a TIM Resolution doc detailing how we look for TIMs:
http://www.terracotta.org/confluence/display/tcforge/Terracotta+Integration+Module+Resolution+and+Versioning+(TC+Version+2.5.1+and+below)
http://www.terracotta.org/confluence/display/tcforge/Terracotta+Integration+Module+Resolution+and+Versioning+(TC+Version+2.5.2+and+up)
I’ll improve the error message, and look at some possible refactoring to improve the error messages that we generate when we fail to locate a TIM.
Juris Galang 2008-04-03
I;ve made the error message include the JAR filename that the Resolver expects when it is unable to locate it.
Closing this, I will create another JIRA for improving the error messages on TIM dependency resolution.
+1 on this. There seems to be a a handful conditions for which we fail to load a module other than simply not locating the file at the proper path, but the messaging (or even the log file) don’t seem to provide any more clues.