LEP is a J2EE open source portal package that implements the Portlet API (JSR 168) and is built on top of Struts and Hibernate.

LEP is an out of box solution that provides personalization, user/group/role management, web email, message boards, document library, wiki, and other content management tools.

LEP is database agnostic and supports: DB2, Firebird, Hypersonic, InterBase, MySQL, Oracle, PostgreSQL, SAP, and SQL Server.

LEP is application server agnostic and supports: JBoss+Jetty/Tomcat, JRun, Oracle9iAS, Orion, Pramati, RexIP, Sun ONE, and WebLogic.

You can demo it at http://my.liferay.com or visit the project site at http://www.liferay.com.

what does your "box solution" mean? besides using liferay as a ready-made portlets and your box,can other person join in development of the "box"?

We used the phrase out of the box solution because it comes with many portlets built in. Liferay comes with web email, doc library, wikis, calendar, and many other useful portlets.

To use them, you simply download, unzip and run. For a production env, simply create the db based on the spec, and change the datasource properties.

However useful the default portlets may be, we recognize it will never solve all solutions and so we aim to make liferay easily customizable.

See http://www.liferay.com/documentation/faq.jsp#3

on how to add/remove your own portlets.

- Brian

Hi brian chen,
   I read part of your code, it seem there are many built-in portlets that don't implement GenericPortlet in liferay. do you have plan to make them to be 168 compliant portlets? would you like to post some papers on forum to describe how portal gets context of portlets?

Can we port portlets from Exo to JetSpeed to Liferay without a rewrite ?

You can port other JSR 168 portlets into Liferay without a problem.

However, porting Liferay's portlets to the other portal servers would require some work because our portlets use many services provided by Liferay.

with portlet container, the portlets can be portable. the portal with container is better architecture

Liferay implements the Portlet JSR 168 spec, meaning it is a portlet container.

However, our older portlets use resources outside the spec, so they do not sit entirely in the container.

Our newer portlets sit entirely inside the container, meaning you can move those to other containers easily.

Our older portlets cannot be moved to other portal containers because they require other resources.

Hi Brian Chan,
    we can not make some processes clear by reading liferay code, such as how portal invoke the portlets to get the context. could you describe the processes on forum.do you plan to write the spec. of interfaces between container and portal, container and application server.

You can get the portlet context by following the portlet API.

For example, in the HelloWorldPortlet, in order to get the context,

you issue the command:

getPortletContext()

it's all in the javadocs that Sun issued on the portlet API.

See

http://jcp.org/aboutJava/communityprocess/final/jsr168/index.html

- Brian

I mean how to communicate between struts and portlet.

See http://www.liferay.com/documentation/development_portlet.jsp

The Hello World, IFrame portlets are completely JSR 168.

Mail, Message Boards, and Calendar conform to JSR 168 but use Struts for any of the complex management. These portlets were written long before JSR 168 came into existence.

We do plan on making all the portlets completely JSR 168 in the future as time permits.

In short, the portal follows JSR 168, some of the portlets follow JSR 168, and some of them follow JSR 168 and our own integration with Struts (backwards compatibility).

Your online demo looks gorgeous... I'll have to download a copy and look around under the covers to see if it'll be a nice solution for my site.

Brian Kapellusch
brewerfan.net

I checked into the liferay portal. It is actually quite cool and they are going to support JSR168.

The only problem. It requires EJB's.

Liferay already supports JSR 168.

Our architecture overview gives arguments for why we chose to use EJBs.

http://www.liferay.com/documentation/architecture_overview.jsp#iv

I agree with industry observer. we think that as far as a portlet container,even a portal to be concerned, ejb is needless. usually paotal or portlet container are web component.

Take a look at the forums:
http://sourceforge.net/forum/forum.php?forum_id=162019
http://sourceforge.net/forum/forum.php?forum_id=162018

Notice how many posts that look like requests for help have "Replies: 0" after them.

Liferay is FANTASTIC at providing a ton of functionality, already built in. Unfortunately, once I moved past the surface to try and get some advanced work done integrating with our environment and portlets, I couldn't get things to work, AND I couldn't get any help from the forums (and it looks like I'm far from alone).

Download it, demo it. If it does what you want by default, I'd recommend it. If you need any customization, keep looking. It's evident to me that the support/community simply isn't there for Liferay.

Hi Rob,

Most of our communication is done via the mailing list.

If you have any questions, feel free to ping us there. Sorry for any of the inconvenience.

- Brian

Are there any internet sites running Liferay today??? is the projct home site running Liferay or just the Myliferay site???

Check out

http://my.316fabrications.com (t-shirt company)
http://www.funambol.com (soccer/palm pilot site)
http://www.scipace.com/ (consulting)

We'll be posting a list of companies and sites that use Liferay on our site shortly (with descriptions of how they use it, etc).

One of the things the liferay portal doesn't do that I asked a while back to have added is "instancing" of portlets. By that, I mean to allow a portlet to appear more than once in the portal page. This feature is extremely important to our application.

Can someone from Liferay comment on when/if this feature will ever appear in Liferay?

That is currently on our todo list.

- Brian

Is there a way of obtaining the documentation (not the API) without file/saving every html page available on the site?

I will start by the conclusion : DO NOT USE LIFERAY.
 
Now I will explain why :
 
Part 1. "Liferay already supports JSR 168" : this is a big LIE. There are months of work to make liferay portal JSR 168 compliant.
 
1.1. NO INDEPENDANT PORTLET WEB APPLICATION
 
Here are some quotes from the specs :
 
"Portlets, servlets and JSPs are bundled in an extended web application called portlet application. Portlets, servlets and JSPs within the same portlet application share classloader, application context and session." (p16)


"The portlet container must load the portlet class using the same ClassLoader the servlet container uses for the web application part of the portlet application After loading the portlet classes, the portlet container instantiates them for use." (p22)



"A portlet application is an extended web application. As a web application, a portlet application also has a servlet context. The portlet context leverages most of its functionality from the servlet context of the portlet application." (p41)
 

"A Portlet Application is also a Web Application. The Portlet Application may contain servlets and JSPs in addition to portlets. Portlets, servlets and JSPs may share information through their session." (p63)

In other words a portlet application is an extended war application and should be deployed as it. BUT in lportal this is not the case at all, the servlet context used is the one oof the portal war, this is also the case of the classloader and the portlet sessions.... You can not deploy a unit war portlet application. Just take the simple Hello World war portlet example from pluto RI, or the portlets given by Sun and try to deploy them on lportal : this is a nightmare. You need to unjar the war, copy the content of the portlet.xml to the UNIQUE portlet.xml located in lportal. This file containes ALL the portlets info of the portal. As a side effect, as every portlets are bundled in the war of the portal, and that the portal uses Struts it makes a hudge and ugly struts config XML file.

That numbers tell everything :

       -portlet.xml : 34ko : 1172 lines

       -web.xml    : 10ko  (it contains all the ejb mappings but that we will focus on that in another point...)

       -stuts-config.xml : 55ko : 1287 lines

Very easy to maintain...

Also, the fact that the class loader is shared between all the portlet in lportal makes it impossible to deploy two portlets that use two different version of a library.

Finally, for the first point, this makes it IMPOSSIBLE to hot deploy portlets.

1.2. Portlet Lifecycle management DOES NOT exist :
 

"During initialization, the portlet object may throw an UnavailableException or a PortletException. In this case, the portlet container must not place the portlet object into active service and it must release the portlet object.  The destroy method must not be called because the initialization is considered unsuccessful." (p22)
 

"The portlet container may reattempt to instantiate and initialize the portlets at any time after a failure. The exception to this rule is when an UnavailableException indicates a minimum time of unavailability. When this happens the portlet container must wait for the specified time to pass before creating and initializing a new portlet object." (p22)
 

"A RuntimeException thrown during initialization must be handled as a PortletException." (p22)
 

"An UnavailableException signals that the portlet is unable to handle requests either temporarily or permanently. If a permanent unavailability is indicated by the UnavailableException, the portlet container must remove the portlet from service immediately, call the portlet’s destroy method, and release the portlet object. A portlet that throws a permanent  UnavailableException must be considered unavailable until the portlet application containing the portlet is restarted." (p27)
 

And you have much more details on how to manage portlets in the specs....

Let's go back to Liferay which is suppose to support all of that. Just make a simple research on the source code to find  UnavailableException and PortletException. You get : NoSuchPortletException which has nothing to do with JSR 168. You get one file and nowhere you get casts to treat portlet unvailibility time period or Runtime exceptions treatment while init or desrtoy.... Come on let's be serious. Don't claim compliance!!! Have you at least read the spec????

1.3 Conclusion of part 1

Lportal is not JSR 168 compliant at all

    -Lportal does not suppoort mutiple portlet wars which brings ugly hudge XML files

    -Lportal does not support hot deployment

    -Lportal does not manage portlet JSR 168 lifecycle at all...

Note that those 3 points represent 80% of the specs implementation work.

Finally,  lportal company can now be sued by Sun Microsystem, they have released a version 2.0 of their portal which claims compliance but which is NOT. The licence of JCP is very strict on that, you need to pass TCK tests to claim compliance. If you don't, Sun can bring you to court. How can a company base its corporate portal on lifferay and trust lportal corporation now?

Part 2 : Lportal design

2.1 EJB for everything

The design of lportal is quite common : stuts that access portlets that access EJB session that contains business logic and a persistent model (using hibernate).

On the lportal site you find :

"Liferay is one of the few portals that has built its portlet container and portlets around Session EJBs. We chose to do this because some of our users needed the distributed capabilities provided by Session EJBs.

Session EJBs provide Liferay with a distributed and transaction based business layer. Yes, this is heavy, and quite unnecessary for many smaller projects, but is essential to many of our users that have large sites."



I don't want to bring the debate on : using EJB or not BUT ALWAYS using them is a design drawback. Look the lportal portlets, lets take the BibleJournal portlet, the addressBook portlet, the poll portlet for example. They are all built on EJB. and you will have many problems to explain me that EJBs are necessary for such applications...


2.2 Have you ever heard about JUnit and unit test, I even to talk about XP programmation...
 

There are 9 Tests classes for the entire portal.....no need to say more

I think that's enougth...

 

You may say that I am rude or anything like that, but I am not, I just tell the truth as I evaluated most of the Open Source portal out there. And I hate beeing taken for a fool. 

Anyway that's just my two cents.

2Julien Boidard:

and what opencsource java-based portal solution would you recommend?

Taras Vasilkevich

I will try to quite precise on the subject.
 

Which Open Source portals are availaible?

You can find a list of OSS portals there : http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java.
Nevertheless between all those choices, some precisions are needed : only three of them have actually a JSR 168 implementation (NOTE this does not mean they are compliant, it just means that you may success to deploy a JSR 168 portlet in them).

Pluto / Jetspeed : pluto is the Reference implementation of the JSR 168 specs. This is not a portal, it is just a portlet container, that of course is compliant (I suppose that they have developped it using the TCK soft). To get a "corpporate portal" you need a portlet container and a portal. Jetspeed 2 (note that jetspeed1.x is not JSR 168 compliant) is suppose to be this portal using pluto has its container. The problem is that there is no release yet and the first beta should be ready in 2004 first quarter : so need to wait for that. One big advantage is that this is an Apache brand... I don't really care on that but manager can.
eXo platform : this is quite a new project but they already have a complete stack (we will come back on what a complete stack means in point 2). It comes with a portlet container and a portal that are two separate modules. You can deploy portlets as unit war application and the servlet class loaders are independant (to point out the same things I did in my lportal analysis). Unlike lportal, the portlet.xml files are clean and not long. There exist two distributions of platform one that use tomcat only and one that introduce jboss as an EJB containrer, you can choose according to your requirements. The problem is that the portlet set is not as important as lportal, but I just saw the last released (beta3) and the actual number of portlets has really increased. I would say that, as JSR 168 is a standard, this is not a big problem, portlets should be portable.
lportal : I think I gave a precise description of it already. I would call lportal a JSR 168 adapter (to use GoF pattern name) and not a portal/portlet container in the spec sense.

The other projects in the linked page are really way behind those 3 (even lportal :) ).
 

What would a portal should contain : the INTEGRATED stack

For me, a "corporate portal" has to be an intergated stack that contains all those things : Portlet container - Portal - CMS - groupware -workflow
 
With such a platform all the operation tasks and learning processes in the company can be efficiently managed.
 
The important point is "Integrated", joining lportal with OpenCMS (your product Taras :) ) in a non tightly way is not a good idea for example. The portal has to be build from the begin with an associated CMS. This is actually the case of Jetspeed2 (using slide project) and the eXo platform using their own product.
 
For the groupware we can say that actually this is not a real problem in portals nevertheless a good organisation model is necessary.
 
Finally, the workflow part. Almost every commercial portals offer such a functionnality and in the OSS world only the eXo platform has such a feature.
 
Conclusion :
 
If you could wait end of 2004 first quarter then wait to see between the eXo platform and jetspeed. (Assuming the eXo platfrom will get and pass the tck). If you can not wait, choose the eXo platform.
 
I personnaly chosed the eXo platform.
 
Hope this is a clear overview of the OSS portal world...keep on with the debate...

Yes. The Exo Portal looks good, but it has a great problem. Is GPL licensed.
That means that is very dificult to use in a commercial development.

We may to wait Jetspeed´s next version

No true.
Check out their license page :http://exo.sourceforge.net/license.html
It states GNU LESSER GENERAL PUBLIC LICENSE

-manish

the eXo platform has a dual licence - à la MySQL - GPL and commercial one that adds warranty.

This page is outof date, I will remove it from the Sourceforge site.

Thanks for the feedback.

the eXo platform also provides a commercial licence where the source is accessible and it adds warranty too.

This commercial licence allows you to distribute your code with eXo bundled without forcing you to use the GPL licence (in other words the commercial licences are non copyleft).

Have a look on our company web site for more information on the licence and when to use the GPL or the commercial one : www.exoplatform.com

The prices of those commercial licences are :
1500€ for the express version
3000€ for the enterprise version

Compare with everything else in the market and tell me if you can find better :)

> The prices of those commercial licences are :
> 1500€ for the express version
> 3000€ for the enterprise version
>
This is a good price but a little bit more clarification is required :
Is this per CPU cost ?
Do you also charge royalties ?

Those prices are per CPU.

If you are an ISP vendor then there are royalties.

If you resell eXo platform licences with your product then you get a discount according to the volume of sells.

Contact us for more precisions

LR has several merits , I am sure Brian can do a better job of defending it
Buts here is what I like about LR so far:

a) Suport for Stateless Session Beans
b) Hibernate for persistance
c) Wide App server platform support
d) struts and tiles : Most of my appdevelopres are very familiar with them -- so learning curve for LR should be more mangeable.
e) struts and tiles for backwards compatibilty : I should be able to take some of my earlier apps based on Struts and Tiles and port them over to LR .

Disclaimer : I am researching Portlets and Portals for an upcoming project; I haven't made up my mind yet.

?
Why even consider small projects like Liferay when professional Windows Sharepoint Services are free bundled with winserver2003?
Tightly integrated with Office 2003 XML and apps like InfoPath?

2,3 years ahead of everything else IMO.

Regards
Rolf Tollerud

How about this assessment...

Sharepoint pros = what you just mentioned
Sharepoint cons = limited to win server 2003 (not free)

vs.

Liferay pros = it's free, run it in Linux, BSD, Solaris, OSX, or Windows
Liferay cons = not tightly integrated with office 2003 xml and apps like infopath

- Brian

> Why even consider small projects like Liferay when professional Windows Sharepoint Services are free bundled with winserver2003?

It's not bundled with Server OS:

http://www.microsoft.com/office/sharepoint/howtobuy/default.mspx

$5600 w/5 Cals. $70/CAL thereafter.

$30000/Server for external connector(ie extranet users) so if you use sharepoint for your corporate face or services it going to cost you.

The portal market is ridiculous nowadays in terms of $$$. Liferay provides small to medium businesses a solid offering for tighter budgets.

You are confusing Sharepoint Portal with Sharepoint Services. The portal is unnecessary. Just put together your own with components from Sharepoint Services - more flexible - more powerful.

Sharepoint Services is bundled with Win Server 2003.
http://www.microsoft.com/windowsserver2003/technologies/sharepoint/default.mspx

Regards
Rolf Tollerud

I completely agree with you in my experience with a number of portal application from vendors, I was closely watching liferay in last year and still, I am not understanding their portal application thoughts, Using EJB???? In each portlets, give me a break dude, this is an idiot thought. People have to think 10 times before considering Liferay for any kind of portal related business purpose

>>>>>

Using EJB actually makes sense for an enterprise portal. It's an established technology, and many people/companies already have expertise in EJB. Also consider the ease of integrating existing projects (based on EJB) to Liferay. EJB's also buy you something that other portals _may_ not: out of the box clustering.
Before I start the usual EJB vs. (insert favorite framework here) flame-war, I will be the first to tell you that EJB has some shortcomings, so please don't let this degnerate into a "EJB sucks" discussion.

I'm certainly no expert on the problems with Liferay's architecture that concern you.

We recently deployed Liferay for an internal portal system and our users love it. Brian's attention to detail is phenomenal. The user experience (though not perfect) is really top-notch. Way beyond anything available in the open-source world.

In the long run, your developers might be happier with your chosen platform. (However, I believe Brian is moving closer to the spec every day). I strongly believe our *users* are getting a much better experience. No offense to the other projects, but they are hideously designed from an aesthetic and usability perspective. Liferay, "right out of the box", provides a wealth of useful, well-thought features wrapped around a nice, clean design. And the main developer Brian is amazingly gracious and helpful. Liferay is a great project and is a testament to Brian's high standards and hard work.

And no, I am not affiliated with Liferay (other than as a user).

I completely agree that the user experience is great with LRP from the moment the server is running... that is an invaluable trait in most real-world, non-techie-biased environments.

For small-to-mid volumes, the product looks like a great win. All the negative comments (too much EJB, degree to which specs are implemented, etc.) are only valuable if they translate into poor product reliability or performance, which does not seem to be the case here. I haven't seen any of the detractors say that they ran stress/volume tests.

LRP is definately worth a serious look and evaluation from any organization considering a portal implementation.

I am actively researching portlets/Portals for an upcomimg project. I have a few questions and I will deeply appreciate any help I can get :

In general how do MVC frameworks fit with Portals ? Does each portal (e.g Exo, Jetspeed, LR) provide its own or can we use any framework ? Can I apply my favorite MVCs like Struts/Tiles or WebWork to portlet development?

How is the presentation tier handled ? Can we reuse existing taglibs ? JSTL ?

I am considering using Portal to visually integrate all the different apps I have . Is it posible using portal/portlets ?

I haven't written a line of portlet code (yet) , so please pardon my ignorance .

MVC isn't defined in the portlet spec.

So it's up to the coder of the portles themselves. Right now, Liferay integrates the portlets with Struts and tiles.

JetSpeed also has certain MVC portlets etc. It's basically portlet implementation specific.

- Brian

As Julien mentioned:

"Nevertheless between all those choices, some precisions are needed : only three of them have actually a JSR 168 implementation (NOTE this does not mean they are compliant, it just means that you may success to deploy a JSR 168 portlet in them)."

Liferay has a JSR 168 implementation, and yes, we are working toward 100% compliance, aka, adding the hot deploy and fixing any implementation bugs. Nonetheless, you can add JSR 168 portlets and they will run. Do you have to write a liferay-portlet.xml as well? Yes. But that's also the case for adding EJBs to weblogic and JBoss, there are situations when you need to add a vendor specific XML descriptor. This is expected.

As for avoiding Liferay, I think this is one of the beauties of open source.

There are many solutions. I even advocate Jetspeed, eXo, plumtree, epicentric, and sharepoint for different clients. Not all clients have the same needs.

Liferay is EJB centric because I find that EJBs have their positives. See Marc Fleury's paper of this issue on jboss.org (I think it's called either blue or white).

Does this mean EJBs don't have drawbacks? Of course not! It's slow and heavy. And so is Java. Compare Java to C++. Why do we choose Java? Even though it's slow compared to C++ (10x to 20x slower), it's worth it because of the portability.

We chose EJBs for the architecture for Polls, Message Boards, Calendar, etc, because it provides a distinct integration advantage. Look at Open USS for example, they were easily able to integrate with Liferay's portlets (even though Open USS is not a JSR 168 portal) because all of our portlets are interfaces exposed via EJBs.

The business logic for our portlets follow the session facade pattern, stateless beans holding all the logic and communicating with Hibernate.

You can't just diss on EJBs without recognizing that some of our clients require the use of EJBs.

As for JUnits, that's one area where we are lacking and are improving on. Thank you for your criticism. I appreciate it with all sincerity.

- Brian

<quote>
2.1 EJB for everything
The design of lportal is quite common : stuts that access portlets that access EJB session that contains business logic and a persistent model (using hibernate).
</quote>

This was the best decision that LPortal has made! We are talking about Stateless Session Beans here... EJB component model gives you a real and standardized business component model. You have a standardized model how to find your components and to create them. Every developers, who know EJB can directly work with them! We (OpenUSS) use the EJB components from LPortal because we only need the business layer and not the presentation layer (we are using XMLC and Enhydra for the presentation layer). It was very easy to integrate LPortal's EJBs into OpenUSS!

C'mon, nowadays we have Open Source EJB containers (JOnAS and JBoss), which are production ready. Using EJB (SSB, MDB, TimerBean and not EntityBean) is the way to go. We don't need another component models for our business layer!

LPortal should stay with EJBs and congratulation to Brian and LPortal team for the 2. version of LPortal!

Cheers,
Lofi Dewanto
OpenUSS http://www.openuss.org