Hey Hi,
I am new to liferay. I am trying to migrate portlets developed in websphere 6.1(JSR 286) to liferay 6.1. For time being I have developed a portal(PA_test.war) displaying some text, which I deployed on liferay.
.war file was chosen to-"Upload a WAR file to install a layout template, portlet, or theme."
After processing following messages were shown- "Your request completed successfully." "The plugin was uploaded successfully and is now being installed."
When I tried looking for portal in plugins installed, I could not find the portal.
I saw the logs where it says :
INFO: Undeploying context [/PA_test]
Jul 30, 2012 7:54:05 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory E:\life\liferay-portal-6.1.0-ce-ga1\tomcat-7.0.23\webapps\PA_test
I want to know :
1) How the portlet is adhering to JSR specifications?
2) What are the major dependency (technology wise) without which the porlet cannot be migrated?
or whether liferay offers an alternative or a bridge to do so
or what's the equialent for websphere 6.1(JSR 286) in liferay?
Please help!!
portlet.xml
<?xml version="1.0"?>
<!--AUTOMATICALLY GENERATED DEPLOYMENT DESCRIPTOR - DO NOT EDIT-->
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.0" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" id="com.bowstreet.portlet.WebAppRunner2_test">
<portlet>
<description xml:lang="en">Portlet to test migration from wpf to xmlpf</description>
<portlet-name>Test Portlet</portlet-name>
<display-name xml:lang="en">Test Portlet</display-name>
<portlet-class>com.bowstreet.portlet.adapter.WebAppRunnerPortlet286</portlet-class>
<init-param>
<name>model</name>
<value>test</value>
</init-param>
<expiration-cache>0</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<supported-locale>en</supported-locale>
<resource-bundle>nls.test</resource-bundle>
<portlet-info>
<title>Test Portlet</title>
<short-title>Test Portlet</short-title>
<keywords>Test Portlet</keywords>
</portlet-info>
<portlet-preferences></portlet-preferences>
</portlet>
<custom-portlet-mode>
<portlet-mode>config</portlet-mode>
</custom-portlet-mode>
<custom-portlet-mode>
<portlet-mode>edit_defaults</portlet-mode>
</custom-portlet-mode>
<user-attribute>
<description xml:lang="en">User Given Name</description>
<name>user.name.given</name>
</user-attribute>
<user-attribute>
<description xml:lang="en">User Last Name</description>
<name>user.name.family</name>
</user-attribute>
</portlet-app>
The portlet class you are using is :
com.bowstreet.portlet.adapter.WebAppRunnerPortlet286
I think this is the problem. This is Websphere specific portlet class. Can you please change it to something like
com.test.portlet.TestPortlet
And then write the test class which extends GenericPortlet
public class TestPortlet extends GenericPortlet {
.........
......
.....
super.doView();
}
or you can extend it by Liferay's MVCPortlet class.
If you think you will be using frameworks to develop portlets such as Struts, Spring, JSF etc., You can create a portlet class by extending respective portlet class provided by these frameworks.
Hope this solves your issue.
As far as I know, Web Experience Factory (formerly WebSphere Portlet Factory) portlets, despite generating JSR (168 or 286) portlet WARs, are currently only licensed for and supported on IBM WebSphere Portal (in addition to JSR APIs, they may also leverage IBM Portal APIs).
I hope that info helps,
..Mike Burati
The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
Related
When I try to invoke local EJB I get EJBAccessException running my migrated Glassfish web application on Wildfly 8.2. I found the JBoss documentation all other than strait forward and need help, i.e. no link to JBoss documentation please.
I have no #DeclareRoles notation on my EJB to make it simple for now. I tried with and without using the security realm other adding jboss-web and jboss-ejb3 to tie the bean to a realm. But I still get the same exception.
I've read these tutorials, but can't get it to work. I am using MongoDB and JDBC security realm setup don't help me much. But for now I bypass the user-role authentication.
Migrating a Java EE App from GlassFish to WildFly
Invoke EJB from WildFly safely
And others
How can I run local EJB on Wildfly in my web application?
#Stateless
public class MyBean {
public String sayHello() {
...
jboss-web.xml
<jboss-web>
<security-domain>other</security-domain>
</jboss-web>
jboss-ejb3.xml
<assembly-descriptor>
<s:security>
<!-- Even wildcard * is supported -->
<ejb-name>*</ejb-name>
<!-- Name of the security domain which is configured in the EJB3 subsystem -->
<s:security-domain>other</s:security-domain>
</s:security>
</assembly-descriptor>
In WildFly 8, such methods which have no explicit security configurations, in a secured bean, will be treated similar to a method with #DenyAll configuration.
This behaviour can be controlled via the jboss-ejb3.xml deployment descriptor at a per bean level or a per deployment level as follows:
<?xml version="1.0" encoding="UTF-8"?>
<jboss:jboss
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:s="urn:security:1.1"
version="3.1" impl-version="2.0">
<assembly-descriptor>
<s:security>
<!-- Even wildcard * is supported where * is equivalent to all EJBs in the deployment -->
<ejb-name>FooBean</ejb-name>
<s:missing-method-permissions-deny-access>false</s:missing-method-permissions-deny-access>
</s:security>
</assembly-descriptor>
</jboss:jboss>
Setting missing-method-permissions-deny-access to false allows access to such methods for all users i.e. the behaviour will be switched to be similar to #PermitAll.
Edit: The only technologies required to reproduce this issue are JSF 2.2 and Spring Boot 1.2.1 + Its embedded Tomcat 8.0.5 server. Everything else listed in this question is just to give context on the tech I'm using.
Update #2: Following along with BalusC's thoughts, I ported my sample custom component into a barebones Servlet 3.1 + JSF 2.2 application. You can find the code for it on Github here.
This simple case does not exhibit the issue I'm describing here. The #FacesComponent annotation works. This heavily implies that the problem is being caused either by Spring 4.1.2 or Spring Boot itself. It's getting late, so I'll be investigating this further tomorrow.
TL;DR: I want to use #FacesComponent and its attributes to replace foundation-components-html.taglib.xml and the <component> entry in faces-config.xml
I currently have custom components working in my project using XML definitions. I recently learned that JSF 2.2 introduced a feature which removes the need for XML entirely. I would love to use this, but when I purely use annotations, they are ignored by JSF. Raw tags show up in my HTML.
(i.e. <custom:paragraph></custom:paragraph>)
I have demonstrated this issue in a sandbox of mine I keep hosted on Github. If you want to take a crack at that, I'll explain how at the bottom of this post.
All you need to do is delete foundation-components-html.taglib.xml, and comment out the faces-config.xml entry for <component> and run the application to encounter the issue. I left it in the 'functioning' state so that anyone who wishes to help has an easy, verifiably correct starting point. Just hit up http://localhost:8080
Technologies Used:
Spring Boot 1.2.1
JSF 2.2 via Mojarra 2.2.6
Embedded Tomcat 8.0.5
NOTE: Remember, this setup currently works, but it's running on the taglib and faces-config entries! My question is how to remove these dependencies using the latest features in JSF 2.2
Full Project
Custom Component
package foundation.components;
import java.io.IOException;
import javax.faces.component.FacesComponent;
import javax.faces.component.UIComponentBase;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
/**
* The Paragraph Component
* #author Seth Ellison
*/
#FacesComponent(value=UIParagraph.COMPONENT_TYPE, createTag=true, tagName="paragraph", namespace="http://www.blah.com/components/html")
public class UIParagraph extends UIComponentBase {
public static final String COMPONENT_TYPE = "foundation.components.Paragraph";
private String value;
private String styleClass;
#Override
public void encodeBegin(final FacesContext facesContext) throws IOException {
// Encode Implementation Omitted for Brevity.
}
#Override
public String getFamily() {
return "blah.components.family";
}
// Getters/Setters...
}
Taglib Definition
<facelet-taglib version="2.2"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facelettaglibrary_2_2.xsd">
<namespace>http://www.blah.com/components/html</namespace>
<tag>
<tag-name>paragraph</tag-name>
<component>
<component-type>foundation.components.Paragraph</component-type>
</component>
</tag>
</facelet-taglib>
Faces Config
<faces-config xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2" metadata-complete="false">
<component>
<component-type>foundation.components.Paragraph</component-type>
<component-class>foundation.components.UIParagraph</component-class>
</component>
</faces-config>
XHTML Template (Stripped down for clarity)
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:jsf="http://xmlns.jcp.org/jsf"
xmlns:custom="http://www.blah.com/components/html">
<head jsf:id="head"></head>
<body jsf:id="body">
<custom:paragraph value="This is a template for a simple marketing or informational website. It includes a large callout called a jumbotron and three supporting pieces of content. Use it as a starting point to create something more unique." />
</body>
</html>
If you'd like to run this, the easiest way would be to download the Spring Tool Suite, grab the code from Github, right click the project, and run it as a Spring Boot App. You'll get a connection error when the JPA configuration fires up, because you (likely) aren't running a local MySQL server. Don't worry about this. It's not at all required to visit the index page and check out the tag status. I frequently run the app both with, and without the DB fired up to no ill effect. Lastly, to get PrettyFaces to play nice with Spring Boot, you have to create either a Symbolic Link or a Hard Link from target/classes into WEB-INF/ -- PrettyFaces is coded to look in WEB-INF/classes or WEB-INF/lib when scanning for annotations.
Snippets for BalusC
This function exists in a class which is marked with #Configuration and implements ServletContextAware
#Bean
public ServletListenerRegistrationBean<ConfigureListener> jsfConfigureListener() {
return new ServletListenerRegistrationBean<ConfigureListener>(
new ConfigureListener());
}
Alright, I figured out what was causing the issue.
This morning I sat down to think about the differences between my working Servlet 3.1 version of the code, and the broken Spring Boot version. The main difference was how the code was being run. Embedded server vs. Standalone.
Spring Boot's embedded Tomcat server was the cause.
When I switched my sandbox around in accordance with this answer, everything turned on normally, and my custom components worked purely off of the #FacesComponent annotation!
I figure this has something to do with the way classes are organized post-startup on the embedded server vs. a discrete deploy to the Pivotal Tomcat server. JSF's annotation scanner seems to simply ignore annotations in that case.
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.
I'm trying to set the project stage for JavaServer Faces in a GlassFish application server v3 with a JNDI property.
I set the stage property to Development stage, but my application received always the Production stage.
I use GlassFish Server Open Source Edition 3.1 (build 43) on a windows system.
For rendering the project stage in the JSF page I use this:
<h:outputText value="Stage:#{facesContext.application.projectStage}"/>
Is anything else necessary to use the project stage in an application? The application has no web.xml file.
Everything is correct, but instead of stage=Development, use value = Development,
i.e. replace stage with value in the property name field.
You need this in your web.xml. It works with 'stage' then.
<resource-ref>
<res-ref-name>jsf/ProjectStage</res-ref-name>
<res-type>java.lang.String</res-type>
<mapped-name>javax.faces.PROJECT_STAGE</mapped-name>
</resource-ref>
This maps the global JNDI property of GF to the reference lookup in JSF.
As a minimum, the following entry needs to be in web.xml:
<resource-ref>
<res-ref-name>jsf/ProjectStage</res-ref-name>
<res-type>java.lang.String</res-type>
<mapped-name>javax.faces.PROJECT_STAGE</mapped-name>
</resource-ref>
The property name depends on what factory class you use:
Use value=Development for org.glassfish.resources.custom.factory.PrimitivesAndStringFactory
Use stage=Development for com.sun.faces.application.ProjectStageJndiFactory
You can also set the resources using asadmin:
C:\glassfish5\bin> asadmin.bat create-custom-resource --restype java.lang.String --factoryclass org.glassfish.resources.custom.factory.PrimitivesAndStringFactory --property "value=Development" javax.faces.PROJECT_STAGE
C:\glassfish5\bin> asadmin.bat create-custom-resource --restype java.lang.String --factoryclass com.sun.faces.application.ProjectStageJndiFactory --property "stage=Development" javax.faces.PROJECT_STAGE
We are in the process of upgrading to WebSphere 7.0 on Windows 2008 R2. Our applications currently run on WebSphere 6.1 on Windows 2003.
We use custom controls we wrote using JSF 1.1 in our applications. Our controls seem to render and interact fine, however whenever we use a JSF HTML component such as:
<%# taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
...
<h:graphicImage url="#{MenuBean.bannerImagePath}" />
We get the following error:
com.ibm.ws.jsp.JspCoreException: Unable to convert string '#{MenuBean.bannerImagePath}' to class javax.el.ValueExpression for attribute url: java.lang.IllegalArgumentException: Property Editor not registered with the PropertyEditorManager
com.ibm.ws.jsp.JspCoreException: Unable to convert string '#{MenuBean.bannerImagePath}' to class javax.el.ValueExpression for attribute url: java.lang.IllegalArgumentException: Property Editor not registered with the PropertyEditorManager
at org.apache.jasper.runtime.JspRuntimeLibrary.getValueFromPropertyEditorManager(JspRuntimeLibrary.java:939)
at com.ibm._jsp._dashboard._jspx_meth_h_graphicImage_0(_dashboard.java:136)
at com.ibm._jsp._dashboard._jspx_meth_f_view_0(_dashboard.java:436)
at com.ibm._jsp._dashboard._jspService(_dashboard.java:109)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1583)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1523)
I have found an article on IBM's website giving a possible fix:
http://www-01.ibm.com/support/docview.wss?uid=swg21318801
However I have removed the specified jars and am still receiving the error message. Again our custom controls seem to work fine under WebSphere 7's JSF 1.2.
Thanks for any help you can provide.
Mike
Listing of WEB-INF\lib
activation.jar
commons-beanutils-1.8.0.jar
commons-collections-3.2.1.jar
commons-dbcp-1.2.2.jar
commons-digester-1.8.1.jar
commons-fileupload-1.2.1.jar
commons-io-1.4.jar
commons-logging-1.1.1.jar
commons-pool-1.4.jar
concurrent.jar
dib-2.0.3.jar
ibatis-2.3.4.726.jar
ifc-3.1.0.jar
imgipt-3.0.0.7.jar
ironeyesql.jar
iText-2.1.5.jar
jasperreports-3.5.0.jar
jaxen-full.jar
jcommon-1.0.12.jar
jdom.jar
jdt-compiler-3.1.1.jar
jfreechart-1.0.9.jar
localization-3.1.0.jar
log4j-1.2.15.jar
mail.jar
mflutil-3.1.0.jar
mmwfoundation-3.1.0.jar
RapidSpellWeb.jar
saxpath.jar
Stedmans.dict
tcr-3.1.0.jar
xalan.jar
xercesImpl-2.4.0.jar
xml-apis.jar
After recompiling against JSF 1.2, rebuilding config files, and updating tld files in the WEB-INF folder, I'm happy to report our problem is fixed. Not exactly sure which fixed the problem. Thanks for your time.
Mike