Ошибка импорта при компиляции JSP "на лету"

У нас есть большая установка веб-приложения, использующая Apache/Tomcat/Jasper и jboss. В среде разработки JSP компилируются на лету. К сожалению, есть один пакет, который не может быть импортирован компиляцией на лету. Для некоторых классов использование полных ссылок вместо импорта работает, но не для всех. Все рассматриваемые классы находятся в одном банке (nonEjb.jar). Предварительная компиляция JSP работает нормально, но, конечно, очень неудобно делать это каждый раз, когда нам нужно изменить один из затронутых файлов. Эта проблема существует уже довольно давно, и я действительно хотел бы решить ее, так как собираюсь проделать некоторую работу в пострадавшем районе.

Вот небольшая тестовая страница. Это не удается для первого импорта. Два импортируемых класса очень похожи, единственная существенная разница заключается в размещении их пакетов. (И да, я проверил правильность объявлений пакетов для обоих классов.)

<%@ page contentType="text/html; charset=utf-8" %>
<%@ page errorPage="/error.jsp" %>

<%@ page import="com.elementk.lms.product.otr.OtrProviderType" %>
<%@ page import="com.elementk.lms.product.course.CourseType" %>

<html>
<body>
<hr>
Displaying the page...
<br>
<%= OtrProviderType.B24x7_PROVIDER.getId() %> value
<br>
<%= CourseType.SELF_STUDY.getId() %> value
</hr>
</body>
<html>

Результат:

09 Mar 2010 21:29:40,555 ERROR [K] [RequestTimingFilter.doFilter:65] Unable to compile class for JSP:

An error occurred at line: 6 in the generated java file
The import com.elementk.lms.product.otr cannot be resolved

Я получаю ту же ошибку, если удаляю импорт и полностью уточняю ссылку (как com.elementk.lms.product.org.OtrProviderType).

Что может быть причиной того, что компилятор JSP находит один из классов, а другой нет?


tomcat jsp
person JST    schedule 09.03.2010    source источник
comment
Сделанный. Я бы включил трассировку стека, но она ничем не отличается от любой другой ошибки компиляции JSP. (В нем нет ничего, что могло бы дать ключ к разгадке проблемы.)   -  person JST    schedule 10.03.2010

Ответы (2)


arrow_upward
3
arrow_downward

Наконец-то мы определили, почему это происходит. Судя по всему, компилятор на лету не различает регистр, а пакет com.elementk.lms.product содержит класс с именем Otr. Компилятор не смог отличить пакет "com.elementk.lms.product.otr" от класса "com.elementk.lms.product.Otr". Это объясняет, почему в сообщении об ошибке упоминается только «com.elementk.lms.product.otr», даже если исходный импорт был «com.elementk.lms.product.otr.OtrProviderType».

Пришлось исправлять, по сути избегая проблемы: мы переименовали пакет.

person JST    schedule 22.04.2010
comment
Большое спасибо! У нас была та же проблема, и мы не могли понять, почему только один из наших пакетов продолжал выдавать эту надоедливую ошибку «Импорт не может быть разрешен». Мы переименовали класс :) - person boes; 19.05.2010
comment
Очень интересно. Мне было интересно, почему я получаю эту ошибку на моем компьютере для разработки Mac (файловая система нечувствительна к регистру), а не на нашем тестовом сервере! Интересно, можно ли это исправить с помощью настройки Tomcat... - person Nic Cottrell; 02.11.2012

arrow_upward
0
arrow_downward

Где находится nonEjb.jar? Ошибка компиляции предполагает, что ее нет в пути к классам (я предполагаю, что имя пакета/класса на 100% правильно и доступно в этом JAR-файле).

Он должен быть помещен как минимум в Webapp/WEB-INF/lib, чтобы JSP распознал его. Альтернативным расположением является Tomcat/lib, но для этого требуется полный административный контроль над сервером, а файл JAR будет доступен для всех развернутых веб-приложений на сервере приложений.

person BalusC    schedule 09.03.2010
comment
Оба упомянутых класса находятся в одном банке (наряду с большим количеством других классов). Это большое веб-приложение, которое существует уже несколько лет, поэтому я могу гарантировать, что проблема не в том, что jar не находится в пути к классам. Теперь мне интересно, есть ли что-то в имени пакета, и я попытаюсь переименовать пакет. - person JST; 10.03.2010