Discussions

News: eXo Portlet Container 2.0 beta

  1. eXo Portlet Container 2.0 beta (16 messages)

    The eXo PC team is pleased to announce the first available implementation of the incoming JSR 286 - Portlet 2.0 specification. This product comes with much functionality:
    • plugin architecture
    • clustering support
    • jsr 286 implementation with:
      • resource serving
      • fragment serving -- AJAX support
      • shared render parameters
      • portlet events (inter portlet communication)
      • portlet filters
      • test portal fully refactored
      • portal maker's framework
    Download from the ObjectWeb forge.
  2. Neat, eXo really seem to have the right ideas. See also: http://www.infoq.com/news/2007/01/exoweb-2-0 The idea of a portal as a WebOS (read Desktop Environment in a browser) is exactly what we need. JSR-286 can't come soon enough for us working with Portals. Any idea when that might be?
  3. Thanks Derek! For those who don't see what a WebOS portal is just check that video in english (but pardon my french...) We now have more than 40 full time employed developers working on it so it comes really really quickly...
  4. The eXo PC team is pleased to announce the first available implementation of the incoming JSR 286 - Portlet 2.0 specification.
    Very interesting. I watched the demo movie, and it definitely looks pretty, and more like a regular desktop. It would be very useful to hear responses from users how they feel about it. Our customers are pointing in the opposite direction, i.e. no desktop metaphor and little or no AJAX (gov. rules -> no JavaScript), so it's cool to see something in the exact opposite direction. Looking at your architecture overview I definitely agree with the general approach to integrating apps though. We are moving to a model where all apps are executing on separate portal instances and/or web containers, and then included into the frontend portal using proxy techniques (like portletbridge.org). That is a very nice model for doing integration, instead of running everything in a single frontend web container, especially from a deployment and security perspective. It's good to see that this model is being promoted!
  5. It would be very useful to hear responses from users how they feel about it.
    Actually they love it. Of course they are beta tester as once again this is a beta but we have seen an incredible adoption for the idea. At the end users just want their life simple and they tend to dislike changes. That new model is a huge technical change but it reproduces an environment that people are familiar with.
    Our customers are pointing in the opposite direction, i.e. no desktop metaphor and little or no AJAX (gov. rules -> no JavaScript), so it's cool to see something in the exact opposite direction.
    That was the same for us, but the role of an editor is to also go further, provide a vision and an implementation of that vision that will at the end deliver a product the customer will even like more. Accessibility laws are good for web 1.0 env but they are to be changed now and regulation people will make them evolve. We can always produce an accessible front office site to show information but the WebOS backoffice is really a plus.
  6. At the end users just want their life simple and they tend to dislike changes. That new model is a huge technical change but it reproduces an environment that people are familiar with.
    Right. But the portal admins and support people I talk to want to minimize the amount of options and choices that their users have to make, and a desktop is more of an "open ended" environment, which can make things problematic. But I guess we can only see if it works once it has been deployed for some time in a large organization.
    That was the same for us, but the role of an editor is to also go further, provide a vision and an implementation of that vision that will at the end deliver a product the customer will even like more.
    Definitely.
    Accessibility laws are good for web 1.0 env but they are to be changed now and regulation people will make them evolve. We can always produce an accessible front office site to show information but the WebOS backoffice is really a plus.
    Right, accessibility laws are mostly for front-office and public functions, but at least around here the "evolution" means that for each revision the laws have more "don'ts" each time... Anyway, again, cool demo!
  7. Accessibility[ Go to top ]

    Looks like we can expect accessibility for rich internet applications within the next year or so: http://www.w3.org/TR/aria-roadmap/#timeline
  8. Benjamin, I watched your video presentation and I downloaded the exoPC-2.0beta-tomcat in the links you gave and it does not have any instructions whatsoever (I apologize in advance if I missed it) to install and configure it. When I started the exoPC-2.0beta-tomcat after installing it on my local machine and I url to http://localhost:8080, http://localhost:8080/portal I was very disappointed with what I saw. If your product is in beta stage I should expect much more from it. Your video presentation looks great and I love the concept. When are we going to see a live demo or when are we going to be able to download and test drive a fully functioning exoPC-2? These are the links I use to download your product. http://www.exoplatform.com/company/faces/public/site http://jcp.org/en/jsr/summary?id=286 Anthony Bisong
  9. The URL The URL to use in your case is http://localhost:8080/ecmportal as the alpha 3 version also bundles the ECM product
  10. btw you downloaded the portlet container not the portal or ecm So what you downloaded is not what you see in the video... Portlet Container != Portal != ECM even if those product are linked in the eXo Suite
  11. btw you downloaded the portlet container not the portal or ecm

    So what you downloaded is not what you see in the video...

    Portlet Container != Portal != ECM even if those product are linked in the eXo Suite
    I am sure most of us that visit theserverside.com know the difference between portal container, portal and portlets. What I am saying is the documentation for installing and configuring the ECM or Exo suite on ExoPC2 beta container is not available on the link you posted. I will download Alpa 3 as you suggested and try it. Thanks Anthony Bisong
  12. Hi Anthony You are right, I should probably detail the eXo Suite offering a little bit more here. So we provide two embeddable products: 1) The eXo Portlet Container That product in its version 1.5 includes a JSR 168 implementation and a WSRP one that work together. It targets ISV that want to bundle it in their own portal solution. Many vendors have done so and dramatically reduce the cost of ownership compare to a built in solution. Our version is also a safer solution and simpler one to use than the reference implementation (pluto) The version we introduce in that thread is eXo PC 2.0 beta which is the implementation of JSR 286. We will also provide a WSRP 2 implementation. 2) The eXo Java Content Repository That product is the implementation of the JSR 170 specification that aims to standardize the way contents are structured, stored, indexed, versioned, locked... The targeted market is the same as for the PC, aka it is the ISV one even if some end user company also use it. The added value compare to the RI is in one hand the performance and in the other hand a large set of clients to communicate with the JCR server (Java WebDAV clent, C# webdav client, Office Plugin, incoming OpenOffice Client, RMI, FTP...) Then we have 2 other higher level products that comes with a user interface as you can see in the video and that are part of a new product line called "eXo Enterprise WebOS" 1) The eXo Portal 2.0 The portal rely on the 2 embeddable products that are the eXo JCR and the eXo PC. The main idea of that one is to simulate inside a browser an OS environment to make it easy for anyone in the company to deal with enterprise application hosted on web servers. The JCR is used to store user pages and preferences (which allows to also manage versions of it...) Currently it is in its version alpha 3 (the one in the video) and does NOT rely on PC 2.0 beta yet but on eXo PC 1.5. So it only comes with a JSR 168 container and not a JSR 286 yet. Should be in a future release though 2) The eXo ECM 2.0 It relies on the Portal 2.0 and provides a set of portlets to handle document management from the capture to the records management and web content diffusion. It bundles several workflow engines like Bonita, JBPM or OncePI. We also have other products in development to push that new paradigm further and i will talk about those a bit later. So I hope that description gives you a better understanding of the eXo Suite :)
  13. Hi Anthony, I'm continuing in the same vein what Benjamin said in his post- What you saw when executing PC2 is simply a basic test Portal aimed at testing JSR 286 Portlets. There is no need to manually integrate eXo ECM and eXo PC. In fact, eXo ECM2-alpha3 already comes with everything put together. I'm taking this opportunity to recapitulate its installation instructions : - Download the package from "http://forge.objectweb.org/project/download.php?group_id=151&file_id=7850". - Unzip it in a directory of your choice, - Chdir to "exo-tomcat/bin/" and execute "eXo.bat run" or "eXo.sh run" depending on your platform, - Browser the URL "http://localhost:8080/ecmportal". And that's it ! HTH -Brice.
  14. Hi, The JSR 286 Portlet API proves to be the ready-made enabler for writing Java-based WebOS applications. Indeed, it tackles many aspects, such as : - Window state control (normal, maximized, minimized), - Inter application communication, - Packaging, - Deployment, - Security, - Internationalization, - User help. Java, through JSR 286, makes it possible to write standard and portable WebOS applications. It also has the advantage of allowing thorough integration with the information system. Some other languages used to implement WebOSes don't offer this approach. This summarizes the concept of "Enterprise WebOS" promoted by eXo Platform. Regards, -Brice.
  15. Java Portlet 2.0 API[ Go to top ]

    The feature that I'm most looking forward to is Resource URL's The Portlet 2.0 API adds javax.portlet.ResourceURL. With a resource url, the portlet can reference PNG's, JPG's, GIF's, JS files, and CSS files. Sean
  16. Accessibility and support for mobile (non-Javascript-enabled) devices - anybody?
  17. Note that the product we have just released is a beta and the implementation is based on JSR 286 early draft 2 (april 2007) in its revision 13. So once again this is an early stage product but the release was made to allow people to start playing with that new technology.