With JSP as far as I could analyse it, it is only possible to run a JSP on the attacker server, not on the victim server. (If somebody can disagree, I would be very happy about an example with code).
So in your case
localhost:8082 must be the attacker server. To run the code the attacker server must also be a web container e.g. Tomcat in which rfi.jsp is served. Otherwise the server will only deliver a text string of the JSP code, not the executed JSP.
<c:import url ="http://localhost:8082/rfi.jsp"/>
would not really be a Remote File Inclusion vulnerability except an evil developer wanted to include the file intentionally during creation of the code. Typically, a file inclusion vulnerability can be triggered from some form of input possibility, mostly by using a query parameter. So it could look like this in the browser url bar to trigger the vulnerability:
rfi.jsp contains code that you want to show as an attacker to the victim.
The victim server code must use
<c:import> allows external URLs,
<jsp:include> does this not, it only works internal so it can open a local file inclusion issue.
A problematic code snippet on the victim side could be:
<%@ taglib uri = "http://java.sun.com/jsp/jstl/core" prefix = "c" %>
<c:import url="<%= request.getParameter(\"myvulnqueryparameter\")%>" />
with a tomcat folder structure similar to:
As for the answer of OscarAkaElvis the extracted code
String p = request.getParameter("p");
@include file="<%="includes/" + p +".jsp"%>"
is not a RFI vulnerable code, this is LFI, and probably difficult because
<%@include> is intended for a static include meaning it is added at compilation time not at runtime (cf https://www.javatips.net/blog/difference-between-static-include-and-dynamic-include).
P.S. I have made some example network for different programming languages with docker in my github repo where you can test it. The above mentioned victim and attack code runs on Apache Tomcat/9.0.21 with JSP 2.3, respectively.