uschindler edited a comment on pull request #551:
URL: https://github.com/apache/lucene/pull/551#issuecomment-998940877
> > Oh, I do believe they will - no doubt about that. This said, I am a
rebel who likes to touch the internals from time to time - if you let people
know they're doing it without any guarantees, I think it's fine. I'll merge the
conflicts against main, maybe later today, and then try to commit it in - will
leave you a placeholder for the check there (or feel free to provide a PR to
this branch, no problem).
>
> My concern is not about rebels, instead I'd just rather not cause hassle:
I'm suspicious of the state of tooling around modules right now :) I can
imagine cases (at least for the near future until stuff matures?) where someone
is running unit tests or using IDE in classpath mode, but then tries to deploy
in module mode for production and gets bit? Obviously, this kind of thing is
what integration tests are for, but it still feels a bit trappy.
I have a solution that works quite well. Not with getCallerClass() as this
needs a special permission. As we only need class name, I use a plain
StackWalker. It just crosschecks that the methods are only called from within
test framework. with or without module does not matter:
```
private static void ensureCaller() {
final Optional<String> caller = walker.walk(s ->
s.map(StackFrame::getClassName).skip(2).findFirst());
if (!caller.orElseThrow().startsWith("org.apache.lucene.tests.")) {
throw new UnsupportedOperationException(
"Lucene TestSecrets can only be used by the test-framework.");
}
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
