Community
Participate
Working Groups
Errors are being logged in an adopter product under certain circumstances where tag classes cannot be located for a tag. The errors are a result of the TagIntrospectingStrategy attempting to analyze tag libraries that are not JSF component libraries. Except for the log entries, there does not appear to be any negative impact. Eg. Exception !ENTRY org.eclipse.jst.jsf.core 4 0 2010-05-27 11:37:04.889 !MESSAGE Bad tag class name in org.eclipse.jst.jsp.core.internal.contentmodel.tld.CMElementDeclarationImpl@37 <snip> !STACK 0 java.lang.Throwable at org.eclipse.jst.jsf.designtime.internal.view.model.jsp.analyzer.TagAnalyzer.cr eateTLDTagElement(TagAnalyzer.java:577) at org.eclipse.jst.jsf.designtime.internal.view.model.jsp.TagIntrospectingStrateg y.resolve(TagIntrospectingStrategy.java:69) at org.eclipse.jst.jsf.designtime.internal.view.model.jsp.JSPTagResolvingStrategy .resolve(JSPTagResolvingStrategy.java:1) at org.eclipse.jst.jsf.designtime.internal.view.model.jsp.AbstractTagResolvingStr ategy.perform(AbstractTagResolvingStrategy.java:42) at org.eclipse.jst.jsf.designtime.internal.view.model.jsp.AbstractTagResolvingStr ategy.perform(AbstractTagResolvingStrategy.java:1) at @ org.eclipse.jst.jsf.common.internal.strategy.StrategyComposite$DefaultComposit @ ionStrategy.compose(StrategyComposite.java:180) at @ org.eclipse.jst.jsf.common.internal.strategy.StrategyComposite.perform(Strateg yComposite.java:66) at @ org.eclipse.jst.jsf.designtime.internal.view.model.jsp.CompositeTagResolvingSt rategy.resolve(CompositeTagResolvingStrategy.java:64) at <snip>
It should be pointed out that, depending on the tag libraries, there will be multiple (we have seen 10) exceptions logged per project per session.
Created attachment 170693 [details] Fix A simple fix that logs the exception only when a trace option (which already exists) is enabled. Since the log entry is really only useful for debugging, this is a consistent solution.
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This is a hotbug request. Adopter product shows multiple instances of an exception being logged for each project in the workspace. * Is there a work-around? If so, why do you believe the work-around is insufficient? No reasonable workaround * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Code review and manual testing. * Give a brief technical overview. Who has reviewed this fix? See comment 2 * What is the risk associated with this fix? none
Approving based on adopter request and low risk nature.
10 per project per session is very bad. And looks safe enough. That new Throwable()); looks pretty odd. Then I saw you are just passing it to the status logger ... to have a stack trace? Up to you.
David, I was just wrapping what had originally been there. I agree with your comment and I have removed the throwable for the checkin.
