There are two main standards in Java portal world :
- portlet API (JSR 168)
- WSRP (Web Services for Remote Portlets
There is only two JSR 168 certified (means passsed Sun TCK tests) portlet container out there :
- Pluto which is the Reference Implementation
- eXo platform portlet container
The first one (pluto) is to make sure portlets are compliant to the specs. The second one (eXo) is also optimized for production use.
There is two project out there for WSRP :
-WSRP4J : reference impl of spec in java
-eXo platform WSRP service
The same comments than for portlet container can be done : one is RI, the other is optimized for production.
No other portal/portlet-container is certified yet.
This is as simple :), it really makes the choice much more simple
Only other Exo installations can consume an Exo producer. I've tried Liferay, uPortal, and several others. They can all consume each other, but no one can consume Exo except Exo. And there is almost no documentation, so you can't find any reason why this is the case.
Worse yet, Exo only has the WSRP proxy portlet for WSRP consumption. That sucks. The WSRP Proxy Portlet is a poor-man's WSRP consumer. It puts the responsibility for configuring WSRP on the user! The user adds the proxy portlet to a page, then must set the URLs and the portlet handle, and such. Every JSR-168 portal gets the WSRP Proxy portlet for free because it is a JSR-168 portlet. The proxy portlet is a cheap-ass way for a portal to brag that they are WSRP compliant.
Say what you want about Exo being ready for production. Its hot-deployment of portlets and its Eclipse plugin make it awesome for development. But if you think it's ready for production, I hope it doesn't interfere with that meth production going on in your basement.
uPortal is the only portal around that has a real WSRP consumer implementation. It lets the administrator add portlets from remote producers to the portal. And it lets the administrator configure access to those portlets. To the user a remote portlet looks like any other portlet (as it should). uPortal's WSRP consumption implementation should be the model for every portal. The only thing uPortal doesn't do right is it doesn't pull the list of available portlets. You have to provide it with the portlet handle, which is a real pain in the ass.
But, as many point out, uPortal sucks for a variety of other reasons. The interface sucks. The themes seem to be an exercise in reproducing the colors of my crap when I'm sick. The overdone use of images is an effort in making page loads take longer than it takes George Bush to pull out of Iraq. And adding a portlet to a page takes about 34 mouse clicks (note to portal designers, BAD DESIGN).
There are two main standards in Java portal world :
- portlet API (JSR 168)
- WSRP (Web Services for Remote Portlets
There is only two JSR 168 certified (means passsed Sun TCK tests) portlet container out there :
- Pluto which is the Reference Implementation
- eXo platform portlet container
The first one (pluto) is to make sure portlets are compliant to the specs. The second one (eXo) is also optimized for production use.
There is two project out there for WSRP :
-WSRP4J : reference impl of spec in java
-eXo platform WSRP service
The same comments than for portlet container can be done : one is RI, the other is optimized for production.
No other portal/portlet-container is certified yet.
This is as simple :), it really makes the choice much more simple
http://www.liferay.com/news/index.jsp
Replies to this comment
Only other Exo installations can consume an Exo producer. I've tried Liferay, uPortal, and several others. They can all consume each other, but no one can consume Exo except Exo. And there is almost no documentation, so you can't find any reason why this is the case.
Worse yet, Exo only has the WSRP proxy portlet for WSRP consumption. That sucks. The WSRP Proxy Portlet is a poor-man's WSRP consumer. It puts the responsibility for configuring WSRP on the user! The user adds the proxy portlet to a page, then must set the URLs and the portlet handle, and such. Every JSR-168 portal gets the WSRP Proxy portlet for free because it is a JSR-168 portlet. The proxy portlet is a cheap-ass way for a portal to brag that they are WSRP compliant.
Say what you want about Exo being ready for production. Its hot-deployment of portlets and its Eclipse plugin make it awesome for development. But if you think it's ready for production, I hope it doesn't interfere with that meth production going on in your basement.
uPortal is the only portal around that has a real WSRP consumer implementation. It lets the administrator add portlets from remote producers to the portal. And it lets the administrator configure access to those portlets. To the user a remote portlet looks like any other portlet (as it should). uPortal's WSRP consumption implementation should be the model for every portal. The only thing uPortal doesn't do right is it doesn't pull the list of available portlets. You have to provide it with the portlet handle, which is a real pain in the ass.
But, as many point out, uPortal sucks for a variety of other reasons. The interface sucks. The themes seem to be an exercise in reproducing the colors of my crap when I'm sick. The overdone use of images is an effort in making page loads take longer than it takes George Bush to pull out of Iraq. And adding a portlet to a page takes about 34 mouse clicks (note to portal designers, BAD DESIGN).
Replies to this comment