Bug 166220 - Allow suppression of "ignoring duplicate definition"
Summary: Allow suppression of "ignoring duplicate definition"
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: LTWeaving (show other bugs)
Version: DEVELOPMENT   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-29 12:11 EST by Ron Bodkin CLA
Modified: 2013-06-24 11:01 EDT (History)
1 user (show)

See Also:


Attachments
This patch makes duplicate jar files a debug-level message, not a warning, since I believe it's a normal, valid configuration. (781 bytes, patch)
2006-11-29 13:45 EST, Ron Bodkin CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ron Bodkin CLA 2006-11-29 12:11:06 EST
In some configurations it's not possible to avoid having jars appear multiple times on the classpath (*). The result is a significant problem, e.g., see http://www.glassbox.com/forum/forum/viewthread?thread=92

I believe this is a normal condition and the warning should be replaced with a INFO level AspectJ trace message instead. However, I'd be happy with an option to suppress this warning (e.g., a dreaded Xlint option?)

(*) Notably on some servers resources in jars in the bootstrap classpath are found multiple times. I've found that the bootstrap classpath is, for some servers, the only location where a jar file can be placed to be shared across all loaders in the system.
Comment 1 Ron Bodkin CLA 2006-11-29 12:11:35 EST
Also, I don't want to suppress all warnings to suppress this one.
Comment 2 Ron Bodkin CLA 2006-11-29 13:45:58 EST
Created attachment 54733 [details]
This patch makes duplicate jar files a debug-level message, not a warning, since I believe it's a normal, valid configuration.
Comment 3 Matthew Webster CLA 2006-12-01 05:50:07 EST
This message and the accompanying logic was added to help solve a genuine configuration problem. I am reluctant to hide a message that 90% of the time indicates that the user has made a mistake and I don't like abusing Xlint. Can you tell me how issuing this message caused the OutOfMemoryError that was reported?
Comment 4 Andrew Clement CLA 2007-10-26 04:03:19 EDT
something we can do here?
Comment 5 Andrew Clement CLA 2013-06-24 11:01:59 EDT
unsetting the target field which is currently set for something already released