SpringMVC class enhance conflict

[wu-sheng]

@candyleer Let's continue the discussion here

Quotes from #3035
@candyleer

I think the best way is do not implement EnhancedInstance(cause spring has some dependcy for interface,if we want make the program work as same as without skywalking agent), we can cache the method and path in the static map cache,and provide do not implement EnhancedInstance mechanism can solve some other problem, such as dubbo-conflict-plugin(which I think it has some side effect if dubbo change the patch class we do)
so I am prepare working on do not implement EnhancedInstance way for springmvc first

@wu-sheng

In the old day(not in SkyWalking), I check about how to do Spring Controller plugin, the reason for EnhancedInstance is that there is no place to put mapping path cache, so most likely, you have to maintain a static map to do so, which cause the performance concern in big system(10k+ Controller methods at least)
I am totally aware this kind of OP has risk, but, actually, if we consider this risk, we can't do anything at any class because any class could be added in Spring context by the end-user, we don't know.
This is why we added Spring patch at first place, could you try to enhance it rather than provide a plugin or remove this field?

[wu-sheng]

@candyleer Is it OK I tag this as an enhance requirement to Spring patch?

[candyleer]

ok

[candyleer]

I think patch is ok, but we may have many unpredictable cases,
So my first thought is to change the class structure less may be safer.
But I ignored the caching problem of very large projects.

[wu-sheng]

I think patch is ok, but we may have many unpredictable cases,
So my first thought is to change the class structure less may be safer.
But I ignored the caching problem of very large projects.

It is OK. I was thinking about that too, but turn out it didn't work. So when you asked about that, I just jumped to the conclusion.