[
https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301876#comment-301876
]
Sean Gurevich edited comment on MEAR-146 at 6/25/12 4:17 PM:
-------------------------------------------------------------
FYI, the library-directory entry in application.xml causes WebLogic 12.1.1 to
throw a "weblogic.deployment.EnvironmentException: duplicate persistence units
with name" when using local development mode and copying EAR to autodeploy
directory. (Not certain of outcome when deploying through AdminServer using
WebLogic's deployer tool.) This problem isn't present under WebLogic 10.3.x
even with the same EAR structure, i.e. packaging libs under APP-INF/lib per
spec. Removing the library-directory entry manually from the application.xml
makes the app work normally under WebLogic 12. I've been watching this issue,
hoping to get an alternative workaround in case WebLogic decided this was a
"feature" in their app server.
The specific problem with the library-directory entry is that, under WebLogic
12, the server attempts to load persistence.xml out of the autodeploy folder as
well as under the <server>/tmp/_WL_user (working area for the deployment). It's
actually the same persistence.xml file, just placed in the tmp work space by
WebLogic.
PS: Our application doesn't care about custom classloading.
was (Author: seanpublic):
FYI, the library-directory entry in application.xml causes WebLogic 12.1.1
to throw a "weblogic.deployment.EnvironmentException: duplicate persistence
units with name" when using local development mode and copying EAR to
autodeploy directory. (Not certain of outcome when deploying through
AdminServer.) This problem isn't present under WebLogic 10.3.x even with the
same EAR structure, i.e. packaging libs under APP-INF/lib per spec. Removing
the library-directory entry manually from the application.xml makes the app
work normally under WebLogic 12. I've been watching this issue, hoping to get
an alternative workaround in case WebLogic decided this was a "feature" in
their app server.
The specific problem with the library-directory entry is that, under WebLogic
12, the server attempts to load persistence.xml out of the autodeploy folder as
well as under the <server>/tmp/_WL_user (working area for the deployment). It's
actually the same persistence.xml file, just placed in the tmp work space by
WebLogic.
PS: Our application doesn't care about custom classloading.
> Expose parameter to not write library-directory element in application.xml
> --------------------------------------------------------------------------
>
> Key: MEAR-146
> URL: https://jira.codehaus.org/browse/MEAR-146
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
> Affects Versions: 2.8
> Environment: Oracle WebLogic
> Reporter: Alex Halovanic
> Priority: Minor
> Attachments: ear-remove-librarydirectory-IT.patch,
> ear-remove-librarydirectory.patch
>
>
> The current handling of defaultLibBundleDir leads to some issues on Oracle
> Weblogic 10+. The Ear plugin currently sets library-directory to the value
> of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's
> classloading features break (specifically "Generic File Loading") when this
> element is set. defaultLibBundleDir has to be set to APP-INF/lib since this
> is the magic library folder for WebLogic.
> The patch adds a parameter to prevent setting library-directory for cases
> like this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
