На сегодняшний день я не нашел способа указать разные пути к классам для сборки и времени выполнения, но с помощью коллеги решение моей конкретной ситуации было найдено. Даже если коннектор не является проектом JDev, зависимый проект может ссылаться на файл jar log4j, который упакован и загружен вместе с ним. Это эффективно имитирует поведение во время выполнения как для автономного, так и для встроенного развертывания контейнера oc4j, в котором веб-приложение и связанный код приложения ссылаются на экземпляр log4j, загруженный загрузчиком классов стороннего JCA-коннектора. Я не думал, что это сработает, если предположить, что библиотека log4j, загруженная двумя разными загрузчиками классов, по-прежнему будет представлять собой два разных экземпляра библиотеки по отношению к статическим инициализаторам log4j. (Это то, что я предполагаю, побуждает log4j генерировать исключение, если оно находит другой экземпляр себя в иерархии загрузчика классов.) По-видимому, это не так, по крайней мере для встроенного сценария. Мне не нужно проверять это для автономного контейнера, так как сборка Maven знает, что не следует включать копию jar библиотеки log4j в файл EAR приложения через «предоставленную» спецификацию области действия в файле сборки. Встроенный контейнер OC4J теперь загружает соединитель JCA, связанный экземпляр библиотеки log4, развертывает приложение и позволяет обоим использовать классы log4j из одного и того же файла библиотеки log4j. Не совсем уверен в том, как взаимодействуют загрузчики классов коннектора и веб-приложений, но теперь это работает.