Hey John,
I use Tomcat myself and have never actually deployed the portal on WebLogic but am willing to rubber duck with you
. Output looks pretty normal, but this looks a little odd to me --
09:57:20,926 DEBUG [[] : '8' for queue: 'weblogic.kernel.Default (self-tuning)'][HookHotDeployListener:1310] Custom JSP files:_null/jsp/html/js/journal/edit_article.js.old_null/jsp/html/portlet/journal/article/content.jsp_null/jsp/WEB-INF/classes/com/liferay/portlet/dynamicdatamapping/dependencies/ddm/documentlibrary.ftl
That's a strange path and the _null? is that normal?
One other thought -- I have also in the past had issues sometimes where hooks roll out but the changes are not seen. It was "cache" related but for me I had to clear the Tomcat work and temp folders before restarting to make sure that all the precompiled and cached stuff was gone. Does WebLogic have something like that?
Lastly, you could try setting this property in your portal-ext.properties
I've had some success with clients facing similar issues (again though, always on Tomcat) whereby undeploying before redeploying seemed to ensure the "new stuff" was picked up.
Give these a shot and let me know what you get.
I use Tomcat myself and have never actually deployed the portal on WebLogic but am willing to rubber duck with you
. Output looks pretty normal, but this looks a little odd to me --09:57:20,926 DEBUG [[] : '8' for queue: 'weblogic.kernel.Default (self-tuning)'][HookHotDeployListener:1310] Custom JSP files:_null/jsp/html/js/journal/edit_article.js.old_null/jsp/html/portlet/journal/article/content.jsp_null/jsp/WEB-INF/classes/com/liferay/portlet/dynamicdatamapping/dependencies/ddm/documentlibrary.ftl
That's a strange path and the _null? is that normal?
One other thought -- I have also in the past had issues sometimes where hooks roll out but the changes are not seen. It was "cache" related but for me I had to clear the Tomcat work and temp folders before restarting to make sure that all the precompiled and cached stuff was gone. Does WebLogic have something like that?
Lastly, you could try setting this property in your portal-ext.properties
#
# Set this to true to undeploy a plugin before deploying a new version. This
# property will only be used if the property "hot.undeploy.enabled" is set
# to true.
#
hot.undeploy.on.redeploy=true
I've had some success with clients facing similar issues (again though, always on Tomcat) whereby undeploying before redeploying seemed to ensure the "new stuff" was picked up.
Give these a shot and let me know what you get.