Я не уверен, какой сервер приложений упоминается здесь, и характер файла common.jar. Сейчас я предполагаю, что сервером приложений является любой контейнер Java EE 5, а файл common.jar является утилитой jar (а не EJB или подобным модулем).
Спецификация платформы Java EE 5 фактически определяет способ, которым поддержка библиотек должна обеспечиваться контейнерами:
Файл .ear может содержать каталог, содержащий библиотеки, упакованные в файлы JAR. Элемент library-directory в дескрипторе развертывания файла .ear содержит имя этого каталога. Если элемент library-directory не указан или файл .ear не содержит дескриптор развертывания, используется каталог с именем lib. Пустой элемент library-directory может использоваться, чтобы указать, что нет никакого каталога библиотеки.
Все файлы в этом каталоге (но не подкаталоги) с расширением .jar должны быть доступны для всех компонентов, упакованных в файл EAR, включая клиенты приложений. Эти библиотеки могут ссылаться на другие библиотеки, либо связанные с приложением, либо установленные отдельно, с использованием любой из методик, описанных здесь.
Это не означает, что метод B является неправильным, он используется для серверов приложений, таких как JBoss 4 , которые не поддерживают элемент library-directory в application.xml. Я считаю, что Glassfish также поддерживает концепцию каталога lib без соответствующего элемента library-directory.
Возвращаясь к вопросу, размещение отдельных классов в каталоге в файле EAR, по-видимому, поддерживается только в WebLogic Server через структуру APP-INF \ classes (разумеется, это не стандарт платформы). Следовательно, рекомендуется использовать jar для общих классов и использовать механизм, поддерживаемый сервером приложений, чтобы сделать эти общие классы доступными для других модулей в приложении.