I have deployed Liferay 6.2 GA4 portal on WebLogic server 10.3.6.0. If the javascript.fast.load property is enabled, the packed javascript version is not got (downloaded) from /combo url. In web browser console the following errors are displayed:
GET https://www.mywebsite.cz/liferay-portal/combo/?browserId=other&minifierType=&languageId=en_US&b=6203&t=1448975784000&/liferay-portal/html/js/aui/color-base/color-base-min.js&/liferay-portal/html/js/aui/event-touch/event-touch-min.js&/liferay-portal/html/js/liferay/dockbar.js 404 (Not Found)
Uncaught TypeError: Cannot read property 'init' of undefined
Due to this for example dockbar doesn't work. From source code it looks like ComboServlet can't get servlet resources found in /combo url parameters. If javascript.fast.load is disabled, portal seems to work.
Weblogic.xml:
<weblogic-web-app
xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.2/weblogic-web-app.xsd"
>
<jsp-descriptor>
<keepgenerated>true</keepgenerated>
<page-check-seconds>60</page-check-seconds>
</jsp-descriptor>
<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-store-type>
</session-descriptor>
<container-descriptor>
<prefer-application-packages>
<package-name>antlr.*</package-name>
<package-name>com.ctc.wstx.*</package-name>
<package-name>org.antlr.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.mozilla.*</package-name>
<package-name>org.xmlpull.*</package-name>
</prefer-application-packages>
<optimistic-serialization>true</optimistic-serialization>
<show-archived-real-path-enabled>true</show-archived-real-path-enabled>
</container-descriptor>
<context-root>/liferay-portal</context-root>
<library-ref>
<library-name>ext-portal-dependencies</library-name>
<specification-version>1.0</specification-version>
<implementation-version>1.0</implementation-version>
<exact-match>false</exact-match>
</library-ref>
</weblogic-web-app>
Does anybody know what could be the problem? Some WebLogic or Liferay settings? Thanks for any idea or help.
I've had a comparable problem long ago on tomcat when there were problems with the temporary file path - e.g. it growing too long. This might happen in a deeply nested filesystem, or when the total path length is limited.
One of the path-length-limiting factors that I'm aware of is an encrypted home folder on Linux. Also, if the temporary filesystem runs full, the compressed file won't be written and consequently can't be served to the browser.
Check something along those lines, and please report back.
After several days of solving the problem I found the main cause of this problem was this:
Because the customer didn't want to have portal dependencies (portal-service.jar, portlet-api.jar, ...) as domain libraries, I deployed it as Java EE Shared Libraries. Obviously it works differently than I expected. So after persuasion of customer, I put liferay dependencies to domain lib folder and suddenly everything started to work.
Related
I would like my server to point to resource files (i.e. css, js, images that are under /resources/default/VERSION_NUMBER/) to AWS S3 instead of delivering the files to the client side by itself.
Here are the relevant libraries and their version number taken from the pom file:
<javax.servlet-api.version>3.0.1</javax.servlet-api.version>
<weld-servlet.version>2.2.9.Final</weld-servlet.version>
<javax.el-api.version>3.0.0</javax.el-api.version>
<el-impl.version>2.2</el-impl.version>
<tomcat-jdbc.version>7.0.47</tomcat-jdbc.version>
<javax.faces.version>2.2.10</javax.faces.version>
<omnifaces.version>2.3</omnifaces.version>
<primefaces.version>6.1</primefaces.version>
I took a look at this post and modified my web.xml file with the following lines:
<context-param>
<param-name>org.omnifaces.CDN_RESOURCE_HANDLER_URLS</param-name>
<param-value>
remote:*=https://[URL]
</param-value>
</context-param>
And updated the library tag in all my css, javascript and image files mentioned in my xhtml file accordingly.
example:
<h:outputStylesheet library="default" name="styles/header.css"/>
Is modified to
<h:outputStylesheet library="remote" name="styles/header.css"/>
Now I am noticing that while the css files are loaded properly from the remote server, the url tags such the following present in the css files (hosted on the remote server) are not being downloaded from the local or remote server
background-image: url("#{resource['remote:images/add-default.png']}") !important;
Note that everything under my resource folder is already hosted in my remote server. I imagine JSF is failing to properly create the url from #{resource['remote:images/add-default.png'}] because in firefox console I get the error "The resource at “” was blocked because content blocking is enabled." for these files.
Once I figure out how to fix this, I would also like to know how to make it so all the jsf resources required on the client side that I don't explicitly specify in my xhtml files can be also hosted in the remote server.
Thank you!
Ok, so... famous saying... this works locally, but not when I deploy.
I recently switched to using Less.js so that I could dynamically change my less variables with Javascript. Again, locally this works like a champ.
In my header I have it referenced:
<link rel="stylesheet/less" type="text/css" href="~/Content/main.less" />
<script src="//cdnjs.cloudflare.com/ajax/libs/less.js/3.9.0/less.min.js"></script>
When I use Visual Studio to deploy this to my Azure App Service I get a 404 on the less file and it all breaks.
I FTP'd into my server and the file is indeed there. https://i.imgur.com/cV5FQOW.png
I double checked to make sure that my properties for the less file are right. I have the build action set to Content and Copy if Newer. https://i.imgur.com/I3DbfHg.png
No matter what I do, if I go looking for that main.less file the azure server returns a 404.
As an FYI, the site is a ASP.Net MVC 5 website. I am using bundling, but only for external css like JQueryUI. I have removed the bundling of my CSS to work with the new stuff.
What am I missing?
Ok! After a bunch of attempts and searches I finally found a related error and found my solution.
This poor gentleman was having an issue serving up JSON files (angular2 app, http request for file json file, 404 on azure) and that made me think I had the same problem.
Eureka! I needed to update my web.config to let it serve LESS files.
<system.webServer>
<staticContent>
<mimeMap fileExtension=".less" mimeType="text/css" />
</staticContent>
<system.webServer>
Hope this helps someone else who runs into the same issue.
I am trying to deploy JSF 1.2 application on WAS 8.5 server. But it is throwing below error on deployment.
Note: In the WAS admin, Under JSF implementation use console, I have selected the "Sun Reference Implementation 1.2 " option . But still problem persist.
[12/17/14 15:12:41:222 PST] 00000095 webapp E com.ibm.ws.webcontainer.webapp.WebApp notifyServletContextDestroyed SRVE0285E: Exception caught while destroying context: {0}
java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>
<listener- class> org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:196)
at org.apache.myfaces.context.servlet.FacesContextImplBase.getApplication(FacesContextImplBase.java:131)
at org.apache.myfaces.webapp.AbstractFacesInitializer._dispatchApplicationEvent(AbstractFacesInitializer.java:261)
at org.apache.myfaces.webapp.AbstractFacesInitializer.destroyFaces(AbstractFacesInitializer.java:293)
at org.apache.myfaces.webapp.StartupServletContextListener.contextDestroyed(StartupServletContextListener.java:153)
at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextDestroyed(WebApp.java:1748)
You should restart the application server (not just the app). You should also make sure jsf-api.api and jsf-impl.jar are not in WEB-INF/lib of your app.
Hello trying to figure out the Jsf (primefaces) and little that goes viz. Compiled war archive in maven try to run through the Glassfish, the server starts but in the beginning writing "Artifact qwe-1.0-SNAPSHOT.war: Server is not connected. Deploy is not available." But in the late writes "Artifact qwe-1.0-SNAPSHOT.war: Artifact is being deployed, please wait... Artifact is deployed successfully." It seems like everything is normal, then opened my page in the browser is empty although in my index.xhtm and my pom.xml and web.xml link pastebin
and should be a button with styles that are connected in primefaces tell me if I'm doing something wrong?
here's a screenshot of the result in the browser. link1
<p:button outcome="productDetail" value="Bookmark" icon="ui-icon-star"> targets you to the productDetail page. If you do not have productDetail.xhtml page at the currect path, the index.xhtml page cannot resolve NavigationCase for outcome. Thus, Create page productDetail.xhtml and put into the same directory of index.xhtml.
In addition, You should use JSF Standard tags(h:head, h:body).
I am planning to use Cometd library in my application that runs on JBoss AS 6. Therefore I downloaded cometd 2.4.0 and tried to deploy example war (from cometd-demo/target) to my AS. I was aware that this was not possible without modifications, so I did the changes in web.xml:
Changed to servlet 3.0 in web-app tag (it is originally 2.5). Used complete tag from CometD faq answer. Also uncommented continuation filter that was already in web.xml, based on this description
Based on faq answer, added async-supported tag. However, this causes problems: if I just uncomment it, web.xml can't be parsed. I found out that this is due to order of tags in XML, so moved async-supported tag down the order, just after load-on-startup tag. However, Jboss still throws exceptions:
ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/cometd-demo-2.4.0].[cometd]]
Servlet.service() for servlet cometd threw exception:
java.lang.IllegalStateException: The servlet or filters that are being
used by this request do not support async operation
ERROR
[org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/cometd-demo-2.4.0].[cometd]]
Servlet.service() for servlet cometd threw exception:
java.lang.ClassNotFoundException:
org.eclipse.jetty.server.AbstractHttpConnection from
BaseClassLoader#12a54b
Complete web.xml file that I use is here.
Example runs no my Jboss despite all errors reported, but by watching firebug, I can see that it does quick pooling instead of long pool. It seems that server thinks that browser has multiple connections open, which is not the case (see JSON below):
[{"id":"137","successful":true,"advice":{"interval":2000,"reconnect":"retry","multiple-clients":true,"timeout":20000},"channel":"/meta/connect"}]
Did anyone managed to make examples work with JBoss as6 and how? What I did wrong here?
remove:
<!-- Portability Filter, needed only to run on non Jetty or non Servlet-3.0 containers -->
<filter>
<filter-name>continuation</filter-name>
<filter-class>org.eclipse.jetty.continuation.ContinuationFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>continuation</filter-name>
<url-pattern>/cometd/*</url-pattern>
</filter-mapping>
from web.xml
I have the same setup and the same problem even if I remove continuation filter from web.xml.
I've found a thread on cometd-users group complaining about multiple-client issue on Tomcat 7 and the cause seems to be a Tomcat bug around Content-Type that is not set to "application/json".
However I've inspected packets and on JBossAS6 the content-type is correctly set on server responses.
UPDATE
I've give a try using Jetty 7 and the problem disappeared. The "multiple-clients" issue affects Tomcat as well as JBoss6 AS