JBoss Portal 2.6 released, including Google gadgets


News: JBoss Portal 2.6 released, including Google gadgets

  1. JBoss.org has released JBoss Portal 2.6, which brings significant improvements in personalization, identity, and workflow. In addition, this release enhances user productivity through integration with Google Gadgets. JBoss Portal 2.6 will be the foundation for the JBoss Enterprise Portal Platform, which will be backed by support subscription and services from Red Hat. New features of JBoss Portal 2.6 focus on:
    • Advanced Personalization: Now users can personalize individual portlets, including themes, layouts, and portlet content, to increase the productivity of specific roles and people within a business process or collaboration effort. Further enhancements include user created user interfaces, drag-and-drop portlets, personalized dashboards and more granular controlled access at the portlet level.
    • Usability Improvements: These include portal and user administration as well as content management. Portlets may be managed overall or for individual instances including default definition. User administration simplifies user creation, provides a list-based view, and includes user search. Basic content management provided out-of-the-box now includes action-based management within a familiar directory view.
    • Content Management System (CMS) Workflow: JBoss jBPM provides content management approval workflow in a configurable process that enables or disables this role-based approval capability.
    • Additional Web Services for Remote Portlets (WSRP) Support: WSRP support offers expanded functionality beyond the basic producer and consumer profiles. Version 2.6 adds implicit cloning capability to both the producer and consumer and supports advanced WSRP profiles.
    • Identity: With JBoss Portal 2.6, developers have pre-built LDAP integration with LDAP server. Supported servers include Red Hat Directory Server, OpenDS, and OpenLDAP.
    • Google Gadget Integration: Now, developers have a simplified way to drop any Google Gadget as portlets. Google Gadgets are mini-applications that work with the Google homepage, Google Desktop, or any page on the web and can range from simple HTML to complex applications. Examples include a calendar, a weather globe, or a media player.
    JBoss Portal is licensed under the LGPL. For more information, download links, or to participate in the project, visit http://labs.jboss.com/jbossportal.

    Threaded Messages (19)

  2. JSR 286[ Go to top ]

    When do you expect support for JSR 286 in JBoss Portal? (Is RedHat/JBoss participating in the JSR-286 expert group?)
  3. Re: JSR 286[ Go to top ]

    We are involved in the JSR 286 expert group (actually I am the representative). We plan to have a compliant portlet container implementation of JSR 286 in 2007. The next major version of JBoss Portal will ship with it, however we haven't fleshed out yet the definitive roamdap, stay tuned!
  4. AJAX[ Go to top ]

    Hi, I see an AJAX invoice viewer demo portlet. What AJAX technologies or frameworks can I use for development of AJAX portlets in JBoss portlets ? Thank you
  5. Re: AJAX[ Go to top ]

    There is no major restriction in terms of Ajax framework that you can use but it doesn't mean that they will all work, YMMV. That said, the Exadel team worked hard to have JBoss Ajax4JSF and JBoss RichFaces working smoothly to build portlets for JBoss Portal. The support for Ajax4JSF has been included in the version 1.1.1 released on June 4th. We are of course keen to hear about your experience of one or several of the hundreds Ajax frameworks on JBoss Portal.
  6. Re: AJAX[ Go to top ]

    the Exadel team worked hard to have JBoss Ajax4JSF and JBoss RichFaces working smoothly to build portlets for JBoss Portal
    So, it's not easy to integrate an AJAX framework in a portal. This is a problem, because if I develop an AJAX application using ICEFaces for Liferay, possibly I never will migrate to JBoss Portal, if JBoss portal does not support it. I think that it's necessary a standard way to create portable AJAX portlets between all Java Portals. Maybe, this is a work for the AJAX frameworks, or for the JSR-286 expert group, or for the portal implementors... What do you think ?
  7. Re: AJAX[ Go to top ]

    RichFaces is not an Ajax framework it's a suite of JSF components using Ajax. Noone can claim that the all JSF components will work out of the box on their portal platform because they won't. RichFaces works to build AJAX JSR-168 portlets designed for any JSR-168 portal. So you are not bound to a portal vendor. (But only really tested on JBoss Portal AFAIK) ICEFaces is unfortunately vendor dependent as of today instead of relying on the JSR-168 portlet spec. I'm willing to make the integration happen with JBoss Portal if they are willing to. When you add JSF into the mix, you also need a standard for JSF bridges for portlets, and the reason why JSR-301 exists. For the DnD we use 'prototype' which is a pure Ajax framework, you can of course use such frameworks on JBoss Portal. The issue is really about aggregation, how do you cope with multiple Ajax frameworks used on the same page by different portlets ? They were just not designed for that. That's why i cannot tell you today. "Go ahead with any of the 100 Ajax framework and you will have no trouble" i'm just being cautious. So the standards are already there or on the way, now Ajax frameworks need to adapt.
  8. ICEfaces and portlets[ Go to top ]

    It's true that the current developer release of ICEfaces (1.6 DR #5) does have basic support for portlets built using ICEfaces running in Liferay. It's an early access release of the portlet functionality and as such we had to make some choices as to what we could support and test. Our community overwhelmingly wanted Liferay support so that's what we tackled first. Our near term road map for the 1.7 release has us properly supporting the JSR 168 spec and more portal containers (which will likely include JBoss). We also have an eye toward the JSR 286 and JSR 301 specs. As Thomas notes, there are some interesting technical challenges to getting multiple portlets using different AJAX frameworks to cooperate on a page. The whole portal thing wasn't really designed with this in mind. However, we realize overcoming these challenges is valuable to our customers so we're doing our best to make it happen. Deryk Sinotte Senior Developer ICEsoft Technologies, Inc.
  9. Re: ICEfaces and portlets[ Go to top ]

    Deryk, ideally nothing would depend on JBoss Portal, but if you need information on our product to speed up its support. I will be glad to help. Feel free to contact me by email, theute at redhat.com if you want.
  10. Integration with JBoss IDE[ Go to top ]

    I'm not (currently) a user of JBoss portal , but the integration with jBPM and other JBoss technologies would cause me to look again at it. Anybody have any comments on how well JBoss Portal integrates with the JBoss IDE (or Red Hat Developer Studio) for development purposes? Paul , Technology in Plain English
  11. c00l[ Go to top ]

    Congratulations on the release! JBoss Portal 2.6 is a major leap forward in usability, interoperability (LDAP/GOOG), and scalability (RHT/QA/Clustering) of the JBoss portal offering. (I no longer have a vested interest to support JBoss... it really is a world-class enterprise portal) Regards, Roy Russo www.loopfuse.com
  12. Julien et. al, Congratulations on your new release! One question: Have you guys gotten portlets using JBoss Seam to run in your portal?
  13. Craig, Some customers/users already use JBoss Seam to write their portlets, it works with some limitations. You can read more here: http://wiki.jboss.org/wiki/Wiki.jsp?page=SeamPortlet
  14. Craig,

    Some customers/users already use JBoss Seam to write their portlets, it works with some limitations. You can read more here: http://wiki.jboss.org/wiki/Wiki.jsp?page=SeamPortlet
    Thank you, Thomas. I asked Gavin about Seam and portlets at JavaOne and he said 'not yet', grumbling under his breath about how JSR-168 is '#%*!ed up.' It's nice to see that you have made some substantive progress in this area. Seam is a well thought out framework and it would be a shame if it could not be used in a portlet.
  15. Congratulations to JBoss Portal community on the release ! One this which really surprise me about JBoss Portal is that it only runs on JBoss Application Server. Being in Open source arena, I feel it should not have such dependency. Also, Liferay recently presented their support for 700 odd combinations as Service Oriented Liferay (SOL). A pretty cool way to express :) Thanks http://www.pcmspace.com
  16. Running on JBoss Application Server is a decision we made a while ago to leverage the benefits of our application server and the services it offers. (pluggable services, like security, transaction management, clustering, farming...) Now that we have the JBoss MicroContainer (http://www.jboss.com/products/jbossmc) that we can use on any application server or servlet container, we have a way to still benefit from the same services and offer a wide offer of supported platforms. We have that in mind for future releases. This 700 number is really easy to make up and means nothing to me. What is meaningful is that it runs on different application server and servlet container. (1 application server * 10 database server * x SSO frameworks supported * y LDAP server supported * z portletframework supported * ... > 700) at the end what is important is that it works for *your* environment (and that you are not locked-in) You can have those zillion of combinations, if you cannot plug it on your existing identity server or if you cannot adapt the framework to your own needs, it is useless. So it's not a question of Open Source arena or not, it's a question of service and professional support you can provide.
  17. We want to isolate JBoss Portal from the underlying EE stack and the next major version of our product will run in other environments. It will not be a major difficulty for us to achieve it.
  18. Also I did not see Thomas's message before but he is right. It means that we will make JBoss Portal run everywhere without any dependency on the target environment. However we will focus on making JBoss Portal being supported on a restricted set of environments, those environments will be tested in our QA labs as it is today for JBoss Portal on JBoss AS. It is easy to run everywhere, it is more difficult to provide support for every combination. Supporting a product for a specified environment has a cost that Red Hat has to pay upfront by investing in the proper QA, and the customer must not pay the price when it runs into troubles in production.
  19. Also, Liferay recently presented their support for 700 odd combinations as Service Oriented Liferay (SOL). A pretty cool way to express :)

    The SOL acronym has a different connotation to me :-) For example, you're SOL if you're using Liferay.... :-)
  20. Hi, some issues have been fixed in richfaces/ajax4jsf Now all richfaces components are working - and ajax4jsf as well ;) see http://jira.jboss.com/jira/browse/RF-186 for details - patches.... CU Mike