We are pleased to announce the release of GridSphere 2.0.2, a JSR 168 portlet compliant portal and portlet container.

The GridSphere Portal Framework offers the following features:

    * 100% JSR 168 Portlet API compliant
    * Portlet API implementation nearly fully compatible with IBM's WebSphere® 4.2.
    * Support for the easy development and integration of "third-party portlets"
    * Higher-level model for building complex portlets using visual beans and the GridSphere User Interface (UI) tag library.
    * Flexible XML based portal presentation description can be easily modified to create customized portal layouts.
    * Built-in support for Role Based Access Control (RBAC) separating users into guests, users, admins and super users.
    * Sophisticated portlet service model that allows for creation of "user services", where service methods can be limited according to user rights.
    * Persistence of data provided using Hibernate for RDBMS database support
    * Integrated Junit/Cactus unit tests for complete server side testing of portlet services including the generation of test reports.
    * GridSphere core portlets offer base functionality including login, logout, user and access control management.
    * Localization support in the Portlet API implementation and GridSphere core portlets support English, French, German, Czech, Polish, Hungarian and Italian.
    * Open-source and 100% free! :-)

 Additionaly, we are releasing gsPortal-0.9, a ready-to-go GridSphere portal distribution containing the following packages:

+ Jakarta Tomcat 5.0.28
+ GridSphere Portal Framework 2.0.2
+ JSRTutorial portlet app.
+ Extras portlet app.
+ JSRPortlets Sun and IBM sample portlets app.
+ JSFPortlets containing Sun sample JSF portlet app.

  The gsPortal distribution can be downloaded from:

http://www.gridsphere.org/gridsphere/gridsphere?cid=download

In addition, please follow the QuickStart guide at

http://www.gridsphere.org/gridsphere/gridsphere?cid=quickstart

to setup and run the GridSphere portal.

  Thanks, The GridSphere Team

Nice! I added your project to Sun's Javapedia

  http://wiki.java.net/bin/view/Javapedia/Portal

I am a total newbie to Portal world but I do see it looming for some of the projects we have in pipeline. I am trying o figure out the Portal landscape. My issues is :

What considerations do you take into account when selecting a Portal? What would be the reason for selecting say Exo over LifeRay or GridSphere over Jetspeed ?

Thanks

Liferay, eXo, GridSphere, and JetSpeed are all very good portals.

JetSpeed:

It's an Apache project and has a large community.

Doesn't have professional support. You're at the mercy of a volunteers.

eXo:

It has a very nice plug and play architecture and is a very good light weight portal.

If you're planning to build on top of eXo and resell your product, look into paying hefty license fees.

Liferay:

Like the rest, it is based on JSR-168 and includes hot deploy of portlets.

Also has the largest number of out of the box portlets (Mail, Wiki, Blogs, Message Boards, Calednar, and more) You can check it out at demo.liferay.net

It's also the prettiest in my opinion, and has a LOT of company support.

For example, check out

http://www.lglifeisgood.com
http://www.liferay.com/company/case_studies/educamadrid.jsp

Over 500,000 students across 1,600 schools use it in Madrid, Spain.

Latest organizations to use Liferay: Dept. of Homeland Security for an emergency response portal. If Liferay is ready to defend the US, it's ready for your organization :)

The largest savings bank in Germany recently released an article on how using Liferay on top of WebSphere saved them in the 6 figure. (http://www.sk-koeln.de)

Liferay is also based on the MIT license, so it's like Apache and BSD and doesn't tie you down.

Bad things about Liferay:

Only has partial WSRP support. JSF support isn't happening until first quarter of next year. Requires a full fledged enterprise J2ee server and is geared for mid to large businesses.

Well, Brian you forget to say that you are Liferay main architect...which probably explains the comments :)

I almost agree to those (especially the cons for Liferay and jetspeed :) ), expect when you say "prettiest", but that is a question of taste!

Benjamin Mestrallet
http://www.exoplatform.com

Also note that the eXo PLatform OEM license are very affordable (and not hefty as you said).

The eXo Platform has by far one of the highest value-to-cost ratio of the market as we provide many functionalities that even closed source commercial vendors such as IBM or BEA does not have.

Benjamin Mestrallet
http://www.exoplatform.com

An overall advantage of GridSphere is support for grid computing. Our niche consumer base is primarily academic research projects interested in grid computing to provide seamless/pervasive access to resources e.g supercomputers for running jobs, high performance storage servers, etc. Most major vendors IBM, HP, Sun, Oracle have announced support for grid computing by backing a set of WS- standards and an Open Grid Services Architecture (OGSA) supported under the Global Grid Forum (www.ggf.org). We offer a collection of grid portlets and we will be providing a release very shortly.

I'm not Liferay developer nor member, so this is my personal opinion:

1.
Technically speaking LPortal is advanced and very cool. I love it! Check out their architecture:
http://www.liferay.com/documentation/architecture/index.jsp

Thanks to this architecture, OpenUSS can reuse their business layer components easily, as we don't use the presentation layer Portlets (we have our own). So the "business component reuse" buzz word is reality in LPortal!

2.
No need to say that LPortal is bad because it needs a full fledge J2EE server. Why? It is very good to use a full fledge J2EE server. Nowadays we have JOnAS, JBoss and Geronimo to come, so this is cool!

3.
Need improvement:
The structure of the sourcecode in the CVS could have some refactoring :-)

Check LPortal CVS:
http://cvs.sourceforge.net/viewcvs.py/lportal/portal/

It's difficult for developers to directly see what kind of components LPortal offers, so if you need to go deep into the code you'll need sometime to be able to understand how the code is structured...

As comparison (OK, I'm bias here :-)):
OpenUSS component structure is based on EJOSA Revolutions.

OpenUSS CVS:
http://cvs.sourceforge.net/viewcvs.py/openuss/openuss/

You can directly see what components OpenUSS offers you. If you choose one of the component, e.g. the discussion forum:
http://cvs.sourceforge.net/viewcvs.py/openuss/openuss/dev-discussion/

you will see all those layers for that chosen component:
model, specification, business, presentation, test.

Each component can be compiled, built and tested separately, which is quite important if you have a big system. Can you imagine that you need to build the whole system to test one component? :-) OpenUSS contains now more than 100 EJBs + those from LPortal - we haven't used every EJBs in LPortal but in our next version OpenUSS 2.0 we will add more of LPortal business component to OpenUSS... So, stay tuned!

It would be very nice to see the next LPortal will have a nice sourcecode structure, so that all the developers can jump into the code a lot more easier. Also through the structure you need to handle the dependencies in explicit manner... For all developers, who want to write their own new LPortal components (Portlets + EJBs) this would be a very important thing! Using EJOSA Revo as you infrastructure would make this process stardardized and a lot more easier to explain.

At the end, why would someone look into an "Open Source" project? Because of its sourcecode, correct? :-)

All in all, thanks a lot to Brian who has provided us with the very nice LPortal solution!

Cheers,
Lofi.

EJOSA - Enterprise Java Open Source Architecture
http://sourceforge.net/projects/ejosa
OpenUSS - Open University Support System
http://sourceforge.net/projects/openuss

Hello Brian,

eXo:

It has a very nice plug and play architecture and is a very good light weight portal.

I think the term "lightweight" deserves a little qualification. As far as I can tell, it refers solely to the fact that Liferay relies heavily on J2EE (EJB in particular) APIs, whereas EXo does not.

Apart from that, I can say from recent experience that Liferay is a very nice, featureful and stable solution. One weakness seems to be in the area of "brandability", i.e. far-reaching adaptation of the layout and appearance. For that, one is forced deep into changing existing, heavily scripted JSPs, which can become a maintenance issue, in particular with product upgrades.

Christian

If you try to deploy your portal into jboss , websphere , Weblogic and wait 1-5mins to test your application and deploy your app into tomcat and wait 10s - 30s to test your application, you will see how "light' and and how "haeavy" it is.

In my opinion, lportal is a 4 years old product and it lacks some latest cool design like IOC , unit testing which is very important for a n small team to control a large source base. If lportal do not rearchitect the design with unit test in mind. I believe that lportal won't keep the development pace with jetspeed2 or exoplatform

Tuan Nguyen
www.exoplatform.com

<quote>
... Weblogic and wait 1-5mins to test your application and deploy ...
</quote>

agree, therefore I propose to use EJOSA, just like OpenUSS. You will never need to deploy everything to test one component. So, this is quite fast.

<quote>
it lacks some latest cool design like IOC
</quote>

sorry, what is so cool with IOC? For me IOC is combination of factory, interface, dependency, pojo. It's not new and not cool :-) If you use Model Driven Development, you actually don't need those IOC container, as you can generate the whole factories, interfaces, codes, etc. - just what you need - automatically. So those XML descriptors - which you need to write and makes your stuffs much more intransparent - from IOC containers are not necessary anymore.

Anyway if you intend to use IOC container - despite of adding complexity, intransparent -, you can also generate a lot of stuffs using MDA tool like AndroMDA. It has a Spring cartridge, at the moment in M3.

Cheers,
Lofi.

Lofi,

How can you say that the use of lighweight containers - which as you said is a combination of xml files (even not necessary) and POJOs - makes your application more intransparent.

Even the EJB 3.0 specification is going that way (unfortunately for you I guess)

The EJB 2.x framework is what we can call an intrusive framework, lighweight containers are not as your POJOs have no idea in which environment they are used which is absolutely not the cased with EJBs.

That is all the difference between POJOs - which can be easily tested outside the scope of any container - and EJBs which are so complex to unit test.

Benjamin

Benjamin,

<quote>
How can you say that the use of lighweight containers - which as you said is a combination of xml files (even not necessary) and POJOs - makes your application more intransparent.
</quote>

sorry, my mistake, I mean:
if I already use an EJB container (with all the EJBs 2.x inside them) and on the top I add an IOC container (Spring, etc...) to wire my EJBs (factories, ...)... This makes my application a lot more intransparent and more complicated.

If you only use only POJO then this is another story... :-) But in a real application you sometimes need MDB. I know that IOC experts would say, no prob, we have done the local Stateless Session Beans "copy" with AOP (transaction support for POJO) and we surely can simulate MDB with POJO as well. But why re-inventing the wheel?

How can you write a portlet (for me a portlet is just another "presentation layer") which needs the functionality of MDB without EJB container? So, in a lot of cases you will need an EJB container, correct? Except you simulate MDBs like I said before.

The point is that, there is nothing wrong using remote and local Stateless SB and Hibernate just like LPortal (please look at the architecture of LPortal, it does not use EntiyBeans!). Portlets are only "presentation layer" components, you still need "business layer" components at the end... :-)

Cheers,
Lofi.

How can you write a portlet (for me a portlet is just another "presentation layer") which needs the functionality of MDB without EJB container? So, in a lot of cases you will need an EJB container, correct?

Good point. Portlets are a curious since they seem technologically poised to usurp much of the Struts audience, yet they're currently seem only to be adopted at the high end. For example eWeek claims that BEA charges $57,000 per CPU for its portal server. So I think its safe to say that portlets are often backed by additional J2EE tiers.

<quote>
Good point. Portlets are a curious since they seem technologically poised to usurp much of the Struts audience, yet they're currently seem only to be adopted at the high end. For example eWeek claims that BEA charges $57,000 per CPU for its portal server. So I think its safe to say that portlets are often backed by additional J2EE tiers.
</quote>

yup, agree.

If you are not only doing some "Hello World" portlet :-), you will surely need a full-fledge J2EE server (for some purposes with e.g. MDB, JCA with SAP, mainframes, EIS, ...). Therefore it is non-sense to say we are lightweight and therefore we are cool (just writing a Hello World portlet is not so cool, IMO) :-)

So, again IMHO, LPortal has a very cool architecture!

Cheers,
Lofi.

"If you try to deploy your portal into jboss , websphere , Weblogic and wait 1-5mins to test your application and deploy your app into tomcat and wait 10s - 30s to test your application, you will see how "light' and and how "haeavy" it is."

If you set Liferay up as an Eclipse project http://sges.homelinux.org/lep you only need to fire it up once and you can hot class swap the changes without restarting JBoss. This is only required to hack the actual portal source. If you are deploying JSR-168 portlets http://sges.homelinux.org/lep/portlets.html you use a similar technique. Keeping your portlets JSR-168 compliant will allow you to move your code base without a lot of effort, so you should be able to develop with a truly light weight container based on Pluto.

How much work would it be to remove the EJB dependency from Liferay? Seeing as portlets are a web based concept, why should you need anything beyond a servlet container to run them? Or is the portlet container free from EJB code, and just some of the exmample portlets require EJBs?

you can of course write and deploy JSR-168 compliant portlets in Liferay. Since the JSR has no dependencies on EJBs, your portlet wouldnt either. In that sense, the portlet container itself is EJB-free.
However, much of the underlying/internal infrastructure (e.g., user management), and most of the portlets included in the distro, rely on EJBs. Changing that would certainly be work, and I dont see much willingness nor a pressing need to approach this.
If you think twice, running the portal on top of JBoss or Geronimo instead of plain Tomcat isnt that much of an issue.

Christian

Some correction on Jetspeed :
+ It is based also on IOC & plugins.
+ You can find more and more IT service companies which are providing support & development on Jetspeed in US, Europe & Asia.
+ It is based on JSR-158.
+ See the new projects which are on the "incubetor process" for the portals.apache.org like brigdes, JCMS, ...

Refresh -> "Do you want to resend POSTDATA?" -> Ew!

It would be a good idea to drop registration requirement to download the stuff!

The links return a tomcat npe message

the second link leads to the following:

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

java.lang.NullPointerException
org.gridlab.gridsphere.layout.PortletLayoutEngine.actionPerformed(PortletLayoutEngine.java:160)
org.gridlab.gridsphere.servlets.GridSphereServlet.processRequest(GridSphereServlet.java:210)
org.gridlab.gridsphere.servlets.GridSphereServlet.doGet(GridSphereServlet.java:127)
javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
org.gridlab.gridsphere.filters.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:72)

note The full stack trace of the root cause is available in the Apache Tomcat/5.0.25 logs.

thanks,
Christian

Sorry about that-- that should be fixed very shortly!

Thanks, Jason

This is great news, keep going :-)

Check out also jPortlet, another opensource Portal with JSR168 portlet container.
I've just release the version 1.0.0M1

Not much in the way of documentation, got anything friendlier? Any quick intro manual?

Is there a comparative analysis between lportal and gridsphere, in terms of speed, ease of use, functionality, support, etc.

so this is like exo but WITH documentation?, what a novel idea

Jelmer,

eXo Platform has more than 120 pages of documentation online, that goes from tutorials, user manual, admin manual, developer manual...

Have a look at :
http://www.exoplatform.com/portal/faces/public/exo/home/community/wiki

Cheers

Benjamin