1 of 1 people found this helpful
Unfortunately GateIn does not currently work on any version of Wildfly.
There will possibly be community availability of Wildfly integration in the future, but there is no timeline for it.
Is there any plan of integrating GateIn Portal with WildFly AS in community?
GateIn is an opensource project so in theory anyone could do it, but just so you know, the project is no longer actively developed by Red Hat employees and we don't plan any new release with WildFly support.
Oh, it's a bad news.
So GateIn has been given up by RH?
What kind of portal container is available to WilfFly AS, LifeRay or something else?
I have tried for more than 8 weeks to integrate GateIn 3.9.x-SNAPSHOT with WildFly AS 10.0.0.CR4, but failed.
I changed some source codes and then packaged GateIn Portal with WildFly AS.
Now WildFly AS can startup successfully with all required applications deployed, but when I try to open the homepage of GateIn Portal, the following errors occur:
2015-12-18 16:43:28,899 DEBUG [portal:ApplicationResourceResolver] (default task-1) Try to extract resource resolver for the url: system:/groovy/portal/webui/application/UIPortlet.gtmpl
2015-12-18 16:43:28,900 INFO [portal:UIPortlet] (default task-1) Could not find portlet with ID : local./redirect-portlet.SiteRedirectPortlet
2015-12-18 16:43:28,912 ERROR [portal:UIPortletLifecycle] (default task-1) Portlet render threw an exception: org.exoplatform.services.portletcontainer.PortletContainerException: org.gatein.pc.api.NoSuchPortletException: No such portlet /redirect-portlet.SiteRedirectPortlet
Caused by: org.gatein.pc.api.NoSuchPortletException: No such portlet /redirect-portlet.SiteRedirectPortlet
I am sure, the portlet of SiteRedirectPortlet is in redirect-portlet.war which is deployed on WildFly AS.
For this error, it seems that the default portal container can't know what portlets in other war applications have been deployed.
Is that the fault of GateIn WCI? How could I to start/stop a WebAppContext in GateIn WCI on WildFly AS?
The needs for portals such as GateIn is diminishing with newer frameworks and approaches.
For instance we realized that people liked GateIn for the user management part (and integration with LDAP...), so for that we have a project called Keycloak now (you'll find ex GateIn-developers there), also some aspects are well served with solutions like an MBaaS (like FeedHenry), in most parts those solutions don't have to be used for mobile only solutions.
For all the UI integration, the world is moving from a server side solution (the problem that the portlet spec was solving) to a client side solution, it willl be even easier once the Web Components specification will be implemented in all browsers.
So instead of embracing a whole solution and be constrained users pick and choose the parts they like and are 100% free to deliver the UI they want (all portals have restrictions).
Unless you are looking for ready-to-go applications to build your "portal" (such as email, forum, calendar, WCM...), in that case Liferay and eXo have their own solution (which happen to be based on the same portlet specification) that you can extend with your own portlets. But I don't know if any of the two works with WildFly yet, this is definitely another constraint of such solutions as you depend on the supported platforms.
Thanks your reply, Thomas.
I am working to upgrade a part of traditional system from JBoss AS 4.2/JBoss Portal 2.6 to WildFly AS/Portal.
It's a complicate legacy system. We hope to upgrade application server and portal container only, so I am trying to find a portal container workable on WildFly AS.
I have worked on GateIn Portal for a few weeks, it's a hard work without knowing much about GateIn Portal details.