Discussions

News: Liferay Enterprise Portal 100% JSR 168 Compliant

  1. LEP is a J2EE open source portal package that is 100% Portlet API (JSR 168) compliant and is built on top of Struts and Hibernate.

    LEP is an out of box solution that provides many portlets for 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.

    Threaded Messages (89)

  2. LEP is built on top of Struts and Hibernate.
    I thought earlier versions of LEP were built on top of entity beans. Is that correct?
  3. Slowness of demo[ Go to top ]

    On the slowness of the demo.

    Our server is an AMD 1.4, but the bottleneck is bandwidth. My church is gracious enough to let me use their 1/3 t1 to host the demo site. After posting this on TSS, we had quite a lot of simultaenous hits. We're in the midst of upgrading to a full t1 (which should alleviate the problems).

    Sorry for the inconvenience.
  4. Don't waste your money[ Go to top ]

    We will take your bandwidth and not pay a penny back. Hope you ain't upgrading just for the sake of folks here seeing your demos.
  5. Don't waste your money[ Go to top ]

    No, we're not upgrading cause of that. We also have a computer lab at church where kids can use to study and play games at. It's our service to the community. Another company came to us and dropped our monthly payments by 15% and upgraded us from a partial t1 to a full t1. So now we spend less and get more.

    We also host lots of local businesses and churches all over the US using Liferay. This is all done as a free gift with no strings attached.

    An example of a tshirt company is www.3sixteen.com
    www.panicrev.org
    my.ccuc.net (church in chicago, many active users, church has 1k ppl, and it piggy backs off of one instance of Liferay)
  6. Yes, older Liferay versions used Entity beans, but were switched over to Hibernate.

    So instead of Struts -> Session Beans -> Entity Beans

    It's now

    Struts -> Session Beans -> Hibernate
  7. Yes, older Liferay versions used Entity beans, but were switched over to Hibernate.So instead of Struts -> Session Beans -> Entity BeansIt's nowStruts -> Session Beans -> Hibernate
    Hallelujah!
  8. Entity Beans to Hibernate switch[ Go to top ]

    Yes, older Liferay versions used Entity beans, but were switched over to Hibernate.
    What was your experience with this switch? Is that the reason why no new version of LEP was released in the last 4 months? Did you see any performance gain using Hibernate? Any productivity gain?
  9. Entity Beans to Hibernate switch[ Go to top ]

    Actually, switching to Hibernate was done around 1.9.x I believe. It wasn't too difficult. We "had" to do it because we wanted support for JRun. JRun entity bean descriptors were very bad. So we sad, if we want JRun support, we basically had to drop entity beans.

    Our design was abstracted one layer down.

    Session Beans -> Java Utility Classes -> Entity Beans

    These Utility classes took care of findByPrimaryKey, countBy,removeBy, update, create, etc etc. These classes are generated.

    So to migrate, we simply updated the generator, and it was done. Performance seems to be a little better, since we could tweak hibernate (it's m-n relationshp is very good), and it's special sql query language is very nice. And now porting to different app servers is cake.
  10. Hello Brian,

    have you looked at Spring yet? (just curious) ;-))

    Cheers,
    Dmitriy.
    Actually, switching to Hibernate was done around 1.9.x I believe. It wasn't too difficult. We "had" to do it because we wanted support for JRun. JRun entity bean descriptors were very bad. So we sad, if we want JRun support, we basically had to drop entity beans.Our design was abstracted one layer down.Session Beans -> Java Utility Classes -> Entity BeansThese Utility classes took care of findByPrimaryKey, countBy,removeBy, update, create, etc etc. These classes are generated.So to migrate, we simply updated the generator, and it was done. Performance seems to be a little better, since we could tweak hibernate (it's m-n relationshp is very good), and it's special sql query language is very nice. And now porting to different app servers is cake.
  11. Are session beans required for custom portlets???? What rendering options are available (JSP, XML/XSL/T, etc..)?

    Jeff
  12. Are session beans required for custom portlets???? What rendering options are available (JSP, XML/XSL/T, etc..)?Jeff
    I was wondering about this process myself. Can't a custom portlet be bundled in a .war with web.xml/portlet.xml files, without using anything but POJOs/servlets, and JSP?
    I'd like to know more about how involved the process is to deploy new portlets.

    Mike
  13. We'll be updating our docs soon to show how easy it is to hot deploy a WAR portlet. It's very simple and you can leave all your code in just the WAR layer.
  14. Up to u[ Go to top ]

    It's entirely up to u. The problem is that you can't have the whole portal
    bundled in .war file unless u get rid of the already Session Beans used throughout the portal & portlets .U may do this by changing business actions into DAO or just simple Hibernate actions which will cost u loads of time.
    Faisal
  15. Experiences[ Go to top ]

    Anybody have any experiences with Liferay? I have steered away from it so far because of the EJB dependency. None of our production applications use EJB, so I develop on Tomcat. If I have to get a full blown EJB container running on my machine in order to demo Liferay - no thanks. Not worth the effort for me, no matter how many people tell it is easy to get a EJB container up and running. Things are never that easy :-)

    On another note, we have been looking for a good Java portal solution for some time. We have looked at eXo and Jetspeed. We plan on looking at GridSphere. So far, I have not been impressed personally. From an "ease of use" prespective, they are all quite lacking. I worked with Epicentric (now Vignette Portal Server) 3 1/2 years ago and was way ahead of what I see in the current open source portal space THEN. That product in its current form looks really impressive, as well. So does IBM's portal server. Oracle has a portal server, but I have been burned by their apps in the past. Plus all of those cost mucho dinero.

    So, I would be interested in hearing some feedback of real world Java portal experiences. Anyone...anyone....Bueller...Bueller.

    Ryan
  16. Experiences (Real World Stuff)[ Go to top ]

    Hey, if you want to check out some real world experiences, look at LG's photo contest. You can tell they use Liferay by the URL.

    http://www.lglifeisgood.com

    College students can upload photos. Students who win get prizes like TVs, phones, and plane trips. I'm sure they saved a ton of $$$ going with Liferay.

    The Madrid, Spain school system just rolled out an implementation using Liferay too. Number of students range up to 500k. I know the guys who worked on the site, and they provide students with chat rooms, communities, email, calendar, and lots of other useful tools.

    http://www.educa.madrid.org/portal/
  17. Portal in action - awesome[ Go to top ]

    That's the best advertisement you can get. I like the look of the site too.
  18. check out uportal[ Go to top ]

    I'd recommend checking out uPortal. It's been in production at many universities for several years and now supports JSR 168. In addition it's open source, and doesn't have any annoying ejb requirements.

    http://www.uportal.org/
  19. check out uportal[ Go to top ]

    Well check out the many on this list:

    http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java/view

    Liferay and uPortal are up there in my list, GlueCode is quite pretty but I'm wondering about its Open Source status. eXo seems more hype that real features. Redhat is feature rich but non-standard.

    Anyway, anyone intersted in putting together a comparison matrix?
  20. check out uportal[ Go to top ]

    Well check out the many on this list:http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java/viewLiferay and uPortal are up there in my list, GlueCode is quite pretty but I'm wondering about its Open Source status. eXo seems more hype that real features. Redhat is feature rich but non-standard. Anyway, anyone intersted in putting together a comparison matrix?
    That would be very useful, albeit a rapidly moving target. For starters, it would be nice to see JSR compliance level.
  21. check out uportal[ Go to top ]

    Sorry to "hijack" your thread Brian, but I want to comment that sentence :
    eXo seems more hype that real features.
    I guess you mean that because we don't provide as many portlets as Liferay, but note that this is a delibarate choice as we see portal as an integration tool that must be adapted for each company usage.

    So in a sense the market targeted by the eXo platform is not directly end users but more ISV and software companies that would build custom business applications on top of the platform. For that kind of market the eXo platform is real and provides some of the best tools of the market like many bridges to integrate existing applications. By the RC1 release we will make an announcement of all the companies that have started to build custom applications on top of eXo platform.

    Finally, we also think that this is the goal of the JSR 168 to allow third parties vendors to create many portlets to be deployed in all compliant portals and not the first role of portal vendors.

    It is just a question of strategy you see...

    Benjamin
  22. check out uportal[ Go to top ]

    Sorry about being a bit too harsh with my wording.

    Anyway, given the many offerings out there its good that you chose a different strategy than the rest of the pack. Well here's hoping that you change the license to something less restrictive.

    Carlos
  23. My be not![ Go to top ]

    The main problem with portals ,even commercial portals is: How useful a portal can be?
    Many portals out there are EMPTY PORTALS. Lifray is not . Liferay is better than many commercial portals. Sybase, for instance, is an empty portal. And most of all it is hard to find a portal as mature as Liferay without having a restricted and an uncomprehensible licence. Developers usually sneek througth the Open Source cause and when their project is well known they switch. Sometimes they leave one version as OS that will never be updated. That means the man behind the project(Brian Chan) has a big heart unlike the rest of the jokers.
    faisal
  24. check out uportal[ Go to top ]

    GlueCode is quite pretty but I'm wondering about its Open Source
    looking at http://www.gluecode.com/website/html/licensing.html

    it apears there are 2 versions of there product

    Gluecode Portal Foundation Server that is released under the GPL
    and Gluecode Advanced Server which is a commercial offering
  25. Experiences[ Go to top ]

    [...] That product in its current form looks really impressive, as well. So does IBM's portal server. Oracle has a portal server, but I have been burned by their apps in the past. Plus all of those cost mucho dinero.So, I would be interested in hearing some feedback of real world Java portal experiences. Anyone...anyone....Bueller...Bueller.Ryan
    Novell Extend Director 5.0 is another very interesting product, but still... cost isn't that low as with Liferay :)
  26. Experiences[ Go to top ]

    My first problem with Liferay (since early versions) is the use of EJB. Portlets are generally created to serve content over HTTP, which means that people expect to use the javax.servlet API's. Why did they ever decide to confuse the matter by introducing EJB's? All they need to do was implement an interface to service beans, and developers could quickly migrate the code to EJB when large scalability becomes an issue. In the short terms, most cross-cutting concerns that are taken care of by EJB (except for transparent RMI) can be replaced with Spring or a similar IoC & AOP implementation. The resulting application would run faster and could be deployed in a servlet container, as all portlet implementations should.

    Has anyone tried to compare this with some of the other portlet frameworks available (JSR 168 compliant or not) like oPortal (http://www.owasp.org/oportal) or JLCP (http://www.jlcp.org)? It would be interested to hear what people have to say about these products. I have tried JLCP, in fact I've been keeping an eye on it for quite a long time and whilst it has some nice features, it does seem to be quite complicated to add custom portlets.

    But one of the quickest and most reliable methods of developing that kind of functionality is frames (pref IFrames ala HTML 4 spec). Portlet functionality in 5 mins!
  27. still jusing JBOSS and EJB...[ Go to top ]

    lemme know when you get rid of EJBs
  28. using it[ Go to top ]

    I evaluated Jetspeed, JBoss Nukes, and Liferay. I chose Liferay and I have been very happy with it. It is well documented. I was able to write a Portlet quickly with no past experience. I would give it a strong recommendation.
  29. About portals in general[ Go to top ]

    Liferay portal: demo is very slow and violates #2 usability rule http://www.useit.com/alertbox/20031110.html

    About portals in general:
    Idea of portlets is appealing but technically wrong: it is inconvenient waste of server resources and less than perfect usability.
    IMO the best-case scenario: Portal/“Portlet”-s should work at client side. Applets/Thinlets/Flashlets are good candidates for portal implementation and they can easily interact with server side by efficient protocols (Hessian, Burlap, IIOP), or less than efficient and less than convenient but popular SOAP.
    Java Web Start or something similar will guarantee client side zero maintenance.

    Ideally user should not be limited to only one portal and depend on mercy of a server side, why not to allow client side portals which will aggregate resources from several server side portals?
  30. About portals in general[ Go to top ]

    That demo looks great but it must be running on a 286 with 16KB of memory on a dial-up modem or something ... it's taking 10 minutes for the main portal page to open!

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  31. About portals in general[ Go to top ]

    That demo looks great but it must be running on a 286 with 16KB of memory on a dial-up modem or something ... it's taking 10 minutes for the main portal page to open!
    Lol. Or maybe the weather service is slow and this slows the entire page ...
    BTW, are portlets info fetched in parralel?

    Regards,
    Horia
  32. About portals in general[ Go to top ]

    Lol. Or maybe the weather service is slow and this slows the entire page ...BTW, are portlets info fetched in parralel?Regards,Horia
    If you plan to run on multiple app servers it's pretty much impossible to fetch in parallel and still stay compliant since you can't / aren't allowed to spawn off threads within the thread of a servlet request. App servers don't prevent this but if you plan to then invoke something that is expecting that request data (say, a portlet) you will probably find that all the request data is not in that new thread or they unwrap the request object that you've wrapped for your implementation. And of course, each app server handles this differently.

    I'd be really curious if Brian found a way around this (I don't feel like looking in the source code for the answer). :) One could always build in a work around for each app server, however, and make it a property to attempt to execute in parallel I suppose.

    -Mike
  33. About portals in general[ Go to top ]

    Hi Mike,

    The portlets on a page are rendered sequentially and not via the threading for exactly the reason you mentioned. I think some other portals do this. I'm not sure how they'd accomplish that and not break compliance. I'd be interested if someone else knew how.
  34. About portals in general[ Go to top ]

    ... The portlets on a page are rendered sequentially and not via the threading for exactly the reason you mentioned. I think some other portals do this. I'm not sure how they'd accomplish that and not break compliance. I'd be interested if someone else knew how.
    As long as JMS is not included in LEP it will be imposible to fetch in parallel portal data. But what about an outside servlet container component (JavaSpaces maybe) that is multithreaded? Even better, include a JMS server in the distribution and you're done.

    Regards,
    Horia
  35. About portals in general[ Go to top ]

    We actually use JMS for the mail sending and other stuff we want to be done via a queue. How would JMS accomplish the other task?
  36. About portals in general[ Go to top ]

    We actually use JMS for the mail sending and other stuff we want to be done via a queue. How would JMS accomplish the other task?
    From the controller component (action class), just send a command message to a queue for each portal that will be displayed. The queue consumer will spawn a thread for each such message fetching the remote data and puting the result in a response queue. Meanwhile the controller component will listen to the response queue for results and as they come in populate the domain objects. The controller knows how many reponse messages has to consume. Only after all the response messages comes in, forward the control to the view. In this way you could achive parallel fetching and so reduce the total time for the fetching to the worst response time of the portlets source.

    Regards,
    Horia
  37. Re: About portals in general[ Go to top ]

    Hi Mike,The portlets on a page are rendered sequentially and not via the threading for exactly the reason you mentioned. I think some other portals do this. I'm not sure how they'd accomplish that and not break compliance. I'd be interested if someone else knew how.
    WebSphere Portal does paralel rendering with Struts. But they use their own implementation of struts controller (Struts 1.1).
  38. About portals in general[ Go to top ]

    That demo looks great but it must be running on a 286 with 16KB of memory on a dial-up modem or something ... it's taking 10 minutes for the main portal page to open!Peace,Cameron PurdyTangosol, Inc.Coherence: Clustered JCache for Grid Computing!
    Works quick for me. And I am behind a slow proxy. Must not be able to handle loads. Maybe they can get big bucks to support their OSS efforts and get better servers. :) On that note I wish the same for Echo.
  39. hold on now[ Go to top ]

    I got to stick up for these guys. I downloaded and installed the tomcat/jboss/hsqldb version. It installed with a single unzip and ran with a single batfile, out of the box with zero tinkering on my part. It ran very fast on my laptop. It was cake to customize the portal and add my own portlet and customize the graphics. Compare to JBoss Nukes, where as of last month when I tried it, you couldn't even change the banner on the portal without writing code.
  40. hold on now[ Go to top ]

    Geoff: I got to stick up for these guys. I downloaded and installed the tomcat/jboss/hsqldb version. It installed with a single unzip and ran with a single batfile, out of the box with zero tinkering on my part. [..] It was cake to customize the portal and add my own portlet and customize the graphics.

    That is all worth noting. I wasn't necessarily saying that their software was too slow ... but something about the configuration (perhaps the bandwidth) was creating a bottleneck.

    Geoff: It ran very fast on my laptop.

    FWIW - That doesn't mean anything! In fact, that is the biggest problem with J2EE apps is that developers with their multi-gigahertz machines and a single user (themselves) think that the software is acceptably "fast," and when it gets rolled out to multiple users it tends to run like a dog, usually because of poor architecture or extremely resource-intensive code. I've seen a 200 user system that saturated a pair of 64-processor Sun e10K's (what's that, about $5 or $10 million?) The developers told me "Well, it runs fine on my machine." :))

    In other words, there's a difference between "single user performance" and "scalable performance."

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  41. hold on now[ Go to top ]

    The bottleneck was our fractional t1 :( Hope we can remedy soon. Sorry for the inconvenience.
  42. hold on now[ Go to top ]

    For performance, my workaround is using apache web server + mod jk + tomcat/jboss.

    http://www.jarchitect.org/loadbalance/index.html
  43. hold on now[ Go to top ]

    For performance, my workaround is using apache web server + mod jk + tomcat/jboss.

    Certainly for some types of bottlenecks (e.g. in the Java code itself,) that will alleviate the bottleneck, although it will cost a lot (hardware) to do it.

    But if the bottleneck is the database, for example, then that will end up just slowing down the app even more.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  44. on my laptop ;-)[ Go to top ]

    Well, I should have noted that the laptop is being used exclusively as a server. But my point in noting the use of my laptop was exactly as you observed ... that i am NOT making performance claims. I don't have the bandwidth or server loading to make any performance claims (though the laptop is a dedicated server sitting on my DSL connection), but their architecture looked sound to me. Given my DSL bandwidth, I doubt I will be able to significantly load the server.

    -geoff
  45. About portals in general[ Go to top ]

    ... Ideally user should not be limited to only one portal and depend on mercy of a server side, why not to allow client side portals which will aggregate resources from several server side portals?
    No problem. Just install LEF on your local machine and point your browser to http://localhost/whatever. :))

    Regards,
    Horia
  46. About portals in general[ Go to top ]

    Liferay portal: demo is very slow and violates #2 usability rule http://www.useit.com/alertbox/20031110.htmlAbout portals in general:Idea of portlets is appealing but technically wrong: it is inconvenient waste of server resources and less than perfect usability. IMO the best-case scenario: Portal/“Portlet”-s should work at client side. Applets/Thinlets/Flashlets are good candidates for portal implementation and they can easily interact with server side by efficient protocols (Hessian, Burlap, IIOP), or less than efficient and less than convenient but popular SOAP.Java Web Start or something similar will guarantee client side zero maintenance.Ideally user should not be limited to only one portal and depend on mercy of a server side, why not to allow client side portals which will aggregate resources from several server side portals?
    Check out this link - http://www.liferay.com/documentation/architecture_overview.jsp
  47. About portals in general[ Go to top ]

    you might want to check out this cool new client side portal framework.

    It's called "frames" and is already supported by most browsers.

    Seriously, the <frame> tag has been much maligned, but since nobody uses Mosaic or Internet Explorer less than version 3.0, I think it's okay to experiment with them again. You can build pretty robust applications with framesets and javascript, and nice UI components with iframes. You can even make the "border" disappear.

    But I was only responding in joking, because frames solve the problems that you propose solving with "thick-client" plugins inside a browser to simulate them.
  48. About portals in general[ Go to top ]

    It's called "frames" and is already supported by most browsers.
    There is even "iframe" tag which is even more suitable, but I still see no reasons for doing rendering on server side.
  49. About portals in general[ Go to top ]

    There is even "iframe" tag which is even more suitable, but I still see no reasons for doing rendering on server side.
    There is the fact that rendering on the server side is the most common way of doing it.

    While there are client side alternatives (such as DreamFactory for example), most people who are looking for a portal want something that follows the portlets spec, which implies server side rendering...
  50. portlets vs iframes[ Go to top ]

    With portlets, since render parameter requests are saved, you get to save the state of the portlet while clicking onto other portlets. You lose that with iframes the minute you leave the page. IFrames also have no concept of preferences or personalization.
  51. About portals in general[ Go to top ]

    There is the fact that rendering on the server side is the most common way of doing it.
    most people who are looking for a portal want something that follows the portlets spec, which implies server side rendering...
    Most people love junk food.
    Most people live in poverty.
    Most people use Windows.
    So what?
  52. About portals in general:Idea of portlets is appealing but technically wrong: it is inconvenient waste of server resources and less than perfect usability.

    Konstatin,
        
        Anything in this universe has less than perfect usability! As for optimal usability, portals can be a good choice if you have the resources. Of course, you can use techniques like caching to reduce processing. Moreover, they may actually save server-side resources when you consider the reduction in round-trips as users navigate to different areas which might otherwise have been shown at once. Or

    IMO the best-case scenario: Portal/?Portlet?-s should work at client side.

    Agree here - client-side portals are better for both usability and resources. BUT in a real-world, most people won't even consider webstart or swing for now. So I'm grateful web-based portal frameworks do exist as they'll remain useful for a long time.
  53. LEP is nice[ Go to top ]

    I have no EJB experience in terms of writing them but some in terms of overall knowledge. I was able to get LEP up and running very quickly. Any questions I did ask were answered very quickly through their mailing list. I would recommend it.
  54. MIT License?[ Go to top ]

    I was expecting this software to GPL'd and was somewhat surprised to see this one instead. Curious about a couple of things:

    1.) Why you chose the license you did and 2.) How does this compare with, say, the GPL? I'm not real familar with it but it sounds fairly friendly to commercial use, like the Apache license.

    Mike
  55. MIT License?[ Go to top ]

    Liferay uses the MIT license because it's very business friendly.

    It's basically identical to BSD and Apache. We just went with MIT cause it sounded cooler :)

    Anyone can modify it and repackage it and sell it.I think the only limitation is that modified source code must still have the license tag on top of it (Same with BSD and Apache).
  56. you got rid of entity beans
    any chance of getting rid of struts aswell?
  57. Struts[ Go to top ]

    Struts is a very useful framework. What would be the reason for removing Struts? We'd just have to use an alternative like WebWork?
  58. Struts[ Go to top ]

    Brian,

    Any thoughts on using JSF? Had to ask :-).

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF FAQ, news, and info
    Struts is a very useful framework. What would be the reason for removing Struts? We'd just have to use an alternative like WebWork?
  59. Struts JSF[ Go to top ]

    JSF Support is on our list of todos.

    Just read your FAQs on JSF Central. Guess we'll have to use Craig's libraries and get them both to work together :)
  60. Pretty good portal (But why EJBs...)[ Go to top ]

    We were searching for better portal product either LGPL or MIT. It looks LEP is the better candidate. But only concern is why did they use EJB at all?
    When they got rid of Entity beans, why did not they do the same with Session beans, too?

    Can anyone from LEP explain what was the reason they gone for EJBs?

    There are many portals available on net and most of them are EJB independent. Though LEP looks better to me compared to others the major concern is dependency on EJB :(
  61. Pretty good portal (But why EJBs...)[ Go to top ]

    Swarraj: There are many portals available on net and most of them are EJB independent. Though LEP looks better to me compared to others the major concern is dependency on EJB :(

    Why does it matter that they use EJBs? Is it because you are using a server that doesn't support EJBs? Or because of some fear of EJBs?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  62. Pretty good portal (But why EJBs...)[ Go to top ]

    Hi Cameron,
    Technology including EJB is not the fear for Developers... introducing new technology in the existing and running old technology is the fear for Management.

    People wearing Developer's hat always find new technology attractive.. There are people wearing management hat too.

    If Tomcat or simple web servers/servlet engines are doing great job for mid size business organizations then replacing these with EJB containers/App Servers is always a risk from management side. I would say that LEP based on EJB is overkill to the needs.

    LEP is wonderful but why they have tight coupling with EJBs was my question and is still not answered by LEP developers. I will wait to see their opnions..

    I hope you got my point.

    Thanks and with best regards

    -Swarraj
  63. Cameron,

    At least you are a loyal to the last!
    (Must give credit when credit is due).

    Regards
    Rolf Tollerud
  64. Why does it matter that they use EJBs?
    Is it because you are using a server that doesn't support EJBs?
    Or because of some fear of EJBs?
    Peace,Cameron Purdy
    More fundamentally, portals are a web-tier technology. The JSR 168 very consciously models itself after the JSP/Servlet specs. It should be possible, of course, for an application developer to write portlets that connect back to EJBs for business logic, if required, but the portal server itself should have no EJB dependencies.

    IBM and BEA have EJB dependencies in their portal products, for obvious reasons. They need to sell expensive app servers, and portals are the latest buzzword to help them do it. But other vendors don't. Vignette's portal server, for example, can run on Tomcat.

    It would be nice if Liferay stuck to the web tier by getting rid of its dependencies on EJBs (even if only Session Beans). Even web containers define a DataSource, so any personalisation information can be stored through the web container's DataSource interface (through Hibernate, of course). It doesn't have to go through the app tier. Yes, it may be architecturally cleaner, but a pure-web strategy is the minimal way to achieve JSR 168 compliance.

    The lower the barriers to entry, the more successful the product.

    Just my two cents.

    Regards,
    Ganesh Prasad
  65. Pretty good portal (But why EJBs...)[ Go to top ]

    Very Well Said Ganesh Prasad!!

    Thanks
    -Swarraj
  66. Great LEP![ Go to top ]

    Brian,

    cool stuff! You have done a great job with LEP! Anyway, IMO, it's wise to choose EJB (EJB =! EB) since this makes it easier for other systems (like OpenUSS) to integrate LEP's business components (business layer). IMO, it is easier to integrate "physical" separated components (just like EJB) as you think and act to have different layers and thus different concerns.

    Regards,
    Lofi.
    http://www.openuss.org

    P.S.: We still work on the new release of OpenUSS + FSL (with LEP's EJBs integration within OpenUSS). It takes longer because we reworked the whole presentation layer (looks good now :-)) and add a multi-perspective concept, just like Eclipse's perspectives but for eLearning stuffs :-)
  67. Why we use EJBs[ Go to top ]

    This is exactly the reason we use EJBs. Lots of companies and other open source projects find integrating with Liferay at the EJB level to be very useful.

    We have looked at Spring and may provide an option in the future where both are available for a deployer to choose from.
  68. Why we use EJBs[ Go to top ]

    Hi Brian,

    I' ve been following Liferay since its early days. Using session bean + Hibernate is a far better solution than Entity Beans. Still there still one problem: If u trace one single business action u find many session bean Home calling other Home(s).This may slow the portal. My suggestion is why u don't use only one single Session Bean for the whole portal
  69. Why we use EJBs[ Go to top ]

    Mike Han's packages have a caching util for the home lookups, so the performance difference should be negligible. We did it mainly for code cleanness. I've read other TSS articles on the diff between Single Session Bean vs. Multiple, but I don't think the answer was decisive?
  70. Why we use EJBs[ Go to top ]

    Mike Han's packages have a caching util for the home lookups, so the performance difference should be negligible. We did it mainly for code cleanness. I've read other TSS articles on the diff between Single Session Bean vs. Multiple, but I don't think the answer was decisive?
    Glad to hear that. The portlets that do exist look great. One other question I had regards hosting multiple portals. This sounds like a really good design feature. I read that this has been tested with Orion, I believe. I admit I haven't had the chance to install the software myself, but does adding another portal require restarting the server for each new portal or is it easier than that?

    Mike
  71. Multiple portals[ Go to top ]

    We've tested it with jboss and orion. Each portal instance requires a WAR file so that the web server knows that it maps to a different virtual host. But once you do that, the db is shared (has a unique company namespace, company maps to virtual host), then you're good to go. So a viable solution would be, take requests for new portals, at the end of the day, add all the necessary xml, reboot, and now you have all the new portals sharing the same resources.
  72. Multiple portals[ Go to top ]

    We've tested it with jboss and orion. Each portal instance requires a WAR file so that the web server knows that it maps to a different virtual host. But once you do that, the db is shared (has a unique company namespace, company maps to virtual host), then you're good to go. So a viable solution would be, take requests for new portals, at the end of the day, add all the necessary xml, reboot, and now you have all the new portals sharing the same resources.
    Brian, I was curious if, taking the idea of hosting multiple companies on the server, you had thought of creating another admin group, say company_admin, that could administer everything in terms of roles, users, portlets, etc. for his company, but would not be able to modify things like datasource, etc. In this way, I would think you could host multiple small business portlets that effectively share the same portal, ala an ASP like intranets.com.

    They just wouldn't have the option of getting their own IP. They're already sharing the same db so I don't think there's anything more secure about using a virtual host from a data perspective. Or maybe there is, and I'm just ignorant of it :).

    Anyway, just curious if you've thought of this approach.

    Mike
  73. Multiple portals[ Go to top ]

    Actually, that is exactly how it's set up right now.

    Administrators are only administrators for their company. We came up with the idea to be like intranets.com, and for starters, we give free portals to churches. So several churches use Liferay for all their email, user management, message boards, wiki, doc lib, etc.

    I think there are ISPs out there that are already taking advantage of this and selling their services to small businesses.
  74. Multiple portals[ Go to top ]

    Actually, that is exactly how it's set up right now.Administrators are only administrators for their company. We came up with the idea to be like intranets.com, and for starters, we give free portals to churches. So several churches use Liferay for all their email, user management, message boards, wiki, doc lib, etc.I think there are ISPs out there that are already taking advantage of this and selling their services to small businesses.
    Thanks for the reply. I was just thinking in terms of a service provider like intranets.com that provides free 30 day trials to potential customers. It seems like it might be a little time and process intensive to modify config files and reboot the server every time you want to perform this setup.

    Mike
  75. Multiple portals[ Go to top ]

    Yes, that's a big limitation for now. Whatever solution we come up with though, if it could fix that issue, would end up being app server specific.
  76. Has anyone checked out Magnolia?[ Go to top ]

    I'm curious as to how Magnolia might compare to LEP. Doe anyone have any experience in comparing the two? Magnolia looks pretty sharp, but I don't have any legitimate experience using it.

    It sets up very easily as well and I had no problems running it on linux or windows and using it in IE and FireFox...

    Anyone?
  77. Sorry...forgot the link:

    http://www.obinary.com/en/magnolia.html
  78. Based on customer requests, we are planning to bundle a portal
    solution with Borland Application Server. For the last month, I did an
    evaluation of several open source portals including jetspeed, exo and
    liferay.

    Here is our selection criteria for an open source Portal Solution

    - Must comply with portlet specification.
    - Must have a clean architecture. A solution based on a huge stack of
    age old technology will be hard to support
    - Must have decent collateral (docs/books/support groups)
    - Must work on our appserver with reasonable ease
    - Support portlet hot deploy feature
    - Must have clear and unambiguous license terms so it can be included
    with our appserver

    We had no bias for/against any of the portals we evaluated. Based on
    the selection criteria above, liferay came on top. I was able to
    build from source, customize it for Borland AppServer, use Borland
    Database JdataStore(This is not one of the database supported by
    Liferay as yet), customize the portal, add new portlets all with
    reasonable ease. Liferay documentation was pretty decent and most
    importantly things worked as documented. I could find the answer to
    couple of uncovered issues in the newsgroup. I did not have to ask a
    single question on the newsgroup to accomplish this.

    The only main issue I found with Liferay was performance. I was
    running it on my fast local desk top (Dell 2 CPU, 2 GHz, 1 GB RAM) but
    it was very slow. In liferay defense, I have not yet precompiled JSPs
    so performance may go up a little when EAR with precompiled JSPs is
    deployed. If we do decide to ship Liferay with our appserver, I intend
    to run OptimizeIt on it and figure out exactly where the performance
    bottlenecks are, resolve them and contribute back changes.

    Liferay does come with a good number of portlets out of box. These are
    useful in small institutes/companies/non-profits where they do not
    have any IT infrastructure. A corporate intranet customer highly
    likely already has calendar, chat etc. Portlets of value there would
    be custom portlets that access company data (sales figures, customer
    data, 401K info etc).
  79. Could you comment/rank the 3 tested portals for each point, I would be quite curious ;).
  80. Here is the numbered list of our crieria:

    1 - Must comply with portlet specification.
    2 - Must have a clean architecture. A solution based on a huge stack of
    age old technology will be hard to support
    3 - Must have decent collateral (docs/books/support groups)
    4 - Must work on our appserver with reasonable ease
    5 - Support portlet hot deploy feature
    6 - Must have clear and unambiguous license terms so it can be included
    with our appserver

    Liferay did great on 1 through 6

    Exo did great on 1, 2, 3. I had trouble getting the EAR to run our
    appserver. There was null pointer exception from
    PortletContainerImp.java:280. Tried to download the source bundle
    tgz so I can debug this further. Tar reported checksum errors on unix
    and ended up with some @LongLink files on windows. I did not have
    time to track down the right version in CVS repository and hence moved
    on. Licensing terms were not clear to me so I sent the license terms
    up the management chain. It is probably sitting in legal for a while
    now.

    Jetspeed did great on 3, 4 and 6 specially 4. I had to make 0 changes to
    make it run on our appserver.
  81. You said too much or not enougth :)[ Go to top ]

    Do you mean hot deploy ear file or hot deploy portlet , I am wonder how can you redeploy the portlet in the ear file with lportal ear file.
  82. You said too much or not enougth :)[ Go to top ]

    Liferay can hot deploy portlet WARs by themselves, so it piggy backs off of the app server's hot deploy features for servlets.
  83. A CIO wouldn't be bothered with how well designed or event some spec compliant a portal is. Usability is the key. Some of the leading portal contains hundreds of EJB Beans .Some run simply on Tomcat. It s getting the job done that counts
    ...not how
  84. Hi Vishi,

    I found that the compilation time for JSPs are very different between JBoss, Orion, WebLogic and other app servers.

    Orion with Jikes takes about 1-2 seconds.

    JBoss without jikes takes about 5-6 seconds

    and WebLogic is even slower without JRockit
  85. Portlets package?[ Go to top ]

    Brian - I've been following your project for a while and am particularly impressed with the quality of its portlets.

    I believe I read a message from you some while ago on a Yahoo portal discussion group that mentioned you were working on a stand-alone re-packaging of those portlets... a package that could be deployed in other 168 containers.

    Has there been any progress on this initiative?

    I tried in vain to get a previous version of the portlets to run properly in BEA Portal 8.1, but the EJB related class loading issues ended up deep sixing the effort :( Workshop did not like my attempt to define a custom class loading structure.

    Keep up the good work!
    cheers,
    Markus
  86. Portlets package?[ Go to top ]

    It's still on our todo list but it's lower in priority. We're working on WebSphere, JOnAS support and other new portlets. We're also updating the docs on how to deploy portlet WARs and hopefully that can come into play in the future.
  87. IFrames[ Go to top ]

    The idea of using IFrames to aggregate loosely coupled components on a page seems appealing to me.

    <brian>
    > With portlets, since render parameter
    > requests are saved, you get to save
    > the state of the portlet while clicking
    > onto other portlets. You lose that with
    > iframes the minute you leave the page.
    </brian>

    Is this really a problem? Most portlets have there own "save" button anyway? I am using an iframe for a stateful, scrollable calendar and I don't loose any state when the user clicks off the calendar?

    <brian>
    > IFrames also have no concept
    > of preferences or personalization.
    </brian>

    Why is this? If you have, say, three frames: top-frame, iframe1 and iframe2, don't they all share the same cookies? And thus the same Session object?

    What would be the draw back of using IFrames. The common thinking has been "frames are evil" so I think most people didn't think about them when it came time to aggregate a bunch of loosely coupled components on one page (i.e. portlets). But it seems to me they have a lot of advantages:

    1. They will execute asynchronously
    2. They will download asynchronously
    3. Maximization is built-in: right-click, "open frame in new window"
    4. Browser caching can be utilized
    5. different portlets can be distributed to different servers with no EJB .

    Issues:
    Context-sharing would be more difficult if the portlets (iframes) came from different servers.

    Q1: Is any one using IFrame to achieve portal-like functionality?
    Q2: Are there any portal vendors that use Iframes?
    Q3: What other issues would arise?
  88. IFrames[ Go to top ]

    using IFrames was my first idea to migrate a struts application to a portlet. But my kickoff reasons for iframes were the following:

    1. isolated context in an iframe
    2. no definition of schemes from the portal in an iframe
    3. scrollbar hierarchies
    4. no portlet context and therefore not a "real" portlet
    5. browser version depended (e.g. netscape 6)

    my opinion is, that iframes only be suitable for simple views...
  89. Hello,

    I am interested in finding:

    a. Liferay developers who might be right for developing a site we’re starting (more info below). If you are a developer, please feel free to email me some info and a link to your site at servers04 dot 12 dot pd at neverbox dot com. A list of Liferay developers/vendors with contact informations (esp. urls) would also be helpful if anyone has such a thing.

    b. A consultant who is versed in a number of open source CMS and portals to help review the proposals we receive (and similar things), and would also appreciate references for this...or, if you are a consultant who is interested, please contact us at servers04 dot 12 dot pd at neverbox dot com with your information.

    We would also welcome anyone who likes the project who wishes to volunteer some time with technical advice, though we understand that most will want to be paid.

    c. Any opinions that people have of Liferay - its reliability, functionality, community, etc.

    We have recently started a non-profit with the mission of bringing high quality news and information from around the web to the public, and we feel Liferay may be a good match for our needs, largely because of its portal-related abilities.

    This is a link to a recent mockup of the front page of the site - http://valuespace.net/quality/For-printout.html

    If you are interested, I can send you more information related to the site.

    Also, please feel free to forward this to any developers or consultants you feel might be well matched for this project.

    Many thanks,

    Peter Dunn
    The Daily Source
    25 Stearns Rd. #2
    Watertown, MA, 02472
    United States
  90. Liferay Implementation[ Go to top ]

    Hi All,

    I'am new liferay and i have insytalled it and .We have a requirement of supporting multiple companies using the same portal server instance. we trying to figure out how we can use one single instance of Liferay Portal server to support multiple companies. Each company will have its own users, its own portlets, look and feel.Is this possible ...Your gr8 help would be appreciated


    Thanks
    Lavanya