[jira] [Commented] (CAMEL-10086) Remove Pattern.compile usages

["Alexandru Enache (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-10086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702975#comment-15702975 ] 

Alexandru Enache commented on CAMEL-10086:
------------------------------------------

I did some digging on this ticket and I've come up with 2 scenarios:

1) There are usages of Pattern.compile that can benefit from the proposed approach (as per the description, making pattern a static variable). The cases when this can take place is when the regex to compile is hardcoded
examples:
{code:title=ArquillianPackager.java}
L472: Pattern propPattern = Pattern.compile("(\\$\\{[^}]*\\})");{code}
{code:title=JsonTokenExtractor.java}
L32: accessTokenPattern = Pattern.compile("\"access_token\":\\s*\"(\\S*?)\"");{code}

2) There are usages of Pattern.compile that cannot be fixed as per the proposed solution (making them static). Both of the examples provided in the description fall in this category. The reason behind this is that the static pattern would be shared by all instances so in a setup like this:
{code}
from("file://target1/?exclude=^.*xml$").to("mock:result");

from("file://target2/?exclude=^.*txt$").to("mock:result");
{code}
the second route would override the pattern that the first route setted up and all messages send to the first route will use the same exclude pattern as the second route. I've also done a test for this specific setup with the static pattern in GenericFileConsumer and I confirm it works as described.

I am still in progress with finding all the places that fall into the 1st category and fixing them, but I will come back with a PR on this.

> Remove Pattern.compile usages
> -----------------------------
>
>                 Key: CAMEL-10086
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10086
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>            Reporter: Mateusz Nowakowski
>            Priority: Minor
>             Fix For: Future
>
>
> Please heck Pattern.compile usage across Camel source code - also *not* direct usage.
> For example: 
> Whenever one of these methods are used from String class a Pattern.compile() is utilized:
> - matches
> - replaceFirst
> - replaceAll
> - replace
> - split: has an optimization and for certain characters it doesn’t use Pattern.compile.
> For example:
> GenericFileConsumer.isMatched calls name.matches(endpoint.getExclude())
> GenericFileEndpoint could contain also excludePattern as well.
> Possible solution:
> Walk through the code and replace usages of these methods with static Pattern variables.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)