Community
Participate
Working Groups
Build Identifier: There's no pattern specified to support JSP fragment files, as a result, these breakpoints can be set in the UI but they are never installed on the target. Reproducible: Always
Created attachment 187588 [details] patch Problem stems from there being duplicate class patterns defined when a file has multiple content types associated with it. The duplicates need to be eliminated.
While the patch looks fine, you did consider using org.eclipse.wst.sse.core.utils.StringUtils#unpack(String), right?
(In reply to comment #2) > While the patch looks fine, you did consider using > org.eclipse.wst.sse.core.utils.StringUtils#unpack(String), right? I had considered it, but I figured that would involving looping twice: once to unpack into a String[] and then again to add those strings to the set. To me, using the tokenizer seemed more efficient.
* 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. Requested by an adopter, as the implementation of classpattern providers caused repeated patterns which prevented breakpoints in JSP fragments from being hit. * Is there a work-around? If so, why do you believe the work-around is insufficient? No * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Existing unit tests have been run. Adhoc testing conducted by myself and Natasha. * Give a brief technical overview. Who has reviewed this fix? This patch eliminates the possibility of breakpoint classpattern providers providing duplicate patterns for files that may have multiple content types. Nitin and Natasha have both reviewed my patch. * What is the risk associated with this fix? Low. The bulk of the changes were made to change concatenation of tokens into storing them in a Set.
Thank you for the reviews. Code has been checked in.
