WeldProxy doesn't recognize source on exception

I'm facing a strange issue in a Java 8 application which use Jax-RS, CDI and run on Wildfly 14.

I have this simple Controller class:

Path("/test")
public class TestController {
private final static Logger logger = LogManager.getLogger();
@GET
@Path("/test")
@Produces(MediaType.APPLICATION_JSON)
public Response test(@Context SecurityContext request) {
try (InputStream is = new FileInputStream("properties.txt")) {
System.getProperties().load(is);
} catch (Exception e) {
logger.error("Error", e);
}
return Response.ok().build();
}

Calling test method will always throw an Exception because properties.txt doesn't exists and this is ok. The strange is that in the stack trace I have a lot of unknown source:

[ERROR] [/test/test] [rest.TestController] Error occurs
java.io.FileNotFoundException: properties.txt
at java.io.FileInputStream.open0(Native Method) ~[?:1.8.0_252]
at java.io.FileInputStream.open(FileInputStream.java:195) ~[?:1.8.0_252]
at java.io.FileInputStream.<init>(FileInputStream.java:138) ~[?:1.8.0_252]
at java.io.FileInputStream.<init>(FileInputStream.java:93) ~[?:1.8.0_252]
at com.testapp.rest.TestController.test(TestController.java:42) ~[classes:?]
**at com.testapp.rest.TestController$Proxy$_$$_WeldClientProxy.test(Unknown Source) ~[classes:?]**
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_252]
[...]

The bold line is the one I'm not understanding. Maybe is a Wildfly bad configuration?

By the way, my Jax-RS initializer is this:

@ApplicationPath("/rest")
public class JaxRsActivator extends Application {
private static final Logger logger = LogManager.getLogger();
private Set<Object> singletons = new HashSet<Object>();
private HashSet<Class<?>> classes = new HashSet<Class<?>>();
public JaxRsActivator() {
LogFactory.useLog4J2Logging();
classes.add(TestController.class);
}	
@Override
public Set<Object> getSingletons() {
return singletons;
}
@Override
public HashSet<Class<?>> getClasses(){
return classes;
}
}

And this is my log4j2.xml

<Configuration status="WARN">
<Properties>
<Property name="basePath">${logDir}</Property>
<Property name="messagePattern">[%-5level] %X{method}[%logger{2}] %msg</Property>
</Properties>
<Appenders>
<Console name="Console" target="SYSTEM_OUT">
<PatternLayout pattern="${messagePattern}\n" />
</Console>
<RollingFile name="File" fileName="${basePath}/app.log" filePattern="${basePath}/app-%d{yyyy-MM-dd}-%i.log" ignoreExceptions="false">
<PatternLayout>
<Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} ${messagePattern}%n</Pattern>
</PatternLayout>
<Policies>
<TimeBasedTriggeringPolicy interval="1" />
</Policies>
<DefaultRolloverStrategy max="5" />
</RollingFile>
</Appenders>
<Loggers>
<Root level="debug">
<AppenderRef ref="Console" />
<AppenderRef ref="File" />
</Root>
<Logger name="org.apache.ibatis.transaction.jdbc.JdbcTransaction" level="ERROR" additivity="false">
<Appender-ref ref="File" level="ERROR" />
<Appender-ref ref="Console" level="ERROR" />
</Logger>
<Logger name="org.apache.ibatis.io" level="ERROR">
<Appender-ref ref="File" />
<Appender-ref ref="Console"/>
</Logger>
<Logger name="org.jboss.resteasy.resteasy_jaxrs.i18n" level="ERROR" additivity="false">
<Appender-ref ref="File" level="ERROR" />
<Appender-ref ref="Console" level="ERROR" />
</Logger>
</Loggers>
</Configuration>

A couple of the comments above have the right answer: for whatever reason, Weld has seen fit to create a client proxy for your resource class. Client proxy sources are not (as a rule) available.

Now, the real question is: why is Weld creating a client proxy for your resource class, given that it has no scope annotation on it, and therefore, you'd think, would be in @Dependent scope? I'm going to guess that RestEasy, the JAX-RS implementation authored by Red Hat and, I assume, shipped as part of WildFly, makes unannotated resource classes @RequestScoped by default, rather than what Jersey does, which is most closely emulated by @Dependent scope. And, most importantly: @RequestScoped objects are proxied.

My "issue" with Weld it's not related with Weld but it's a fault in my Exception hierachy which cause a loss in stack trace.