TSS Article: Return of the eXo Portal Platform

Discussions

News: TSS Article: Return of the eXo Portal Platform

  1. TSS Article: Return of the eXo Portal Platform (21 messages)

    Benjamin and the eXo team are back. The eXo platform is an open source, JSR 168 implementation, enterprise portal built from several modules. Exo is based on innovative tools, APIs and frameworks such as JavaServer Faces, the Pico Container, JbossMX and AspectJ.

    This article delves into the changes in the updated eXo portal platform.

    It delves deeper into the Inversion of Control aspects of the platform, as well as interesting issues such as technology bridging (using Struts with eXo), JavaServer Faces, the universal deployer, and many code examples.

    Read What's new in the eXo platform

    Visit the eXo Platform Home

    Threaded Messages (21)

  2. Yes, we are back on TSS :)

    The biggest news is probably the fact that the eXo platform is JSR 168 compliant. Indeed, we signed Sun Microsystems' TCK licence and passed all the tests. We are currently the only Open Source portal to offer such a compliance (appart pluto which is the Reference Implementation).

    This new version also comes with an eclipse plugin.

    Finally note that the eXo platform is not any more dependant on the JBoss application server : it is currently possible to deploy it on tomcat (4 and 5), Jetty, JBoss and the Websphere Application Server version is on the way.

    Have a merry Xmas
  3. Congratulations with JSR compliance to the eXo team! This is great news for the OSS portal space.
  4. Hello Aslak,

    Thanks, have a look at the article. There is quite a long section on how we use Pico within an appplication server, how we clearly split the service API and their implementation and finally how most of our components are IoC type 3 (portlets, portlet filters, message listener, action handlers in our portlet framework).

    Cheers,

    Benjamin
  5. Price?[ Go to top ]

    After spending a fruitless half-hour browsing the site trying to find more information on your ISV license, I came up empty handed. Could you please feel free to let us know how much you would charge if we were to use the portlet platform with commercial, non GPL, portlets, taking advantage of your extra goodies etc. etc.

    This information is not at all obvious or easy to come by, unless I missed something....
  6. Price?[ Go to top ]

    As specified in the article, we define two commercial licences to complete the GPL one :

    - the end user licence
    - the ISV licence

    For the end user licence two versions are availables - the express and the entreprise. The former costs 1500 euros and the latter 3000 euros per CPU.

    As to the ISV licence, the cost is not fixed. Obviously, it depends on the contract we pass with the company regarding its business and a potential partnership we can build. For anyone in this case, we recommend contacting us directly for more precise information: licence at exoplatform dot com

    Actually we don't sell the end user licences on line yet, as we are still in the R&D phase.

    Regards, Benjamin
  7. Websphere Support?[ Go to top ]

    Can we deploy eXo platform portal on websphere? If yes please give some links for getting useful help in this regard.
  8. Websphere Support?[ Go to top ]

    Hi ,

    You should use our forum at http://exo.sourceforge.net/forum/index.php.
    Yes , We have a developer report that he make exo work with WAS version 5.1.
  9. jBPM vs WfMC?[ Go to top ]

    Does anybody know if jBPM is WfMC compliant? Is jPdl compliant with XPDL? ( I dont think it mentions it anywhere, so probably not).
  10. jBPM vs WfMC?[ Go to top ]

    No jBpm is not compliant to any of the numerous specs. I'm writing an article on this topic (workflow concepts & standards) and hopefully floyd will publish it here. I expect to finish it before end of januari. So keep an eye on TSS and the jbpm.org website.

    Regards, Tom.
  11. This is the first reasonable Java project I have seen for years. Congratulations. I can see no faults with it. Standard portlet API, no default EJB; JSF modeled after .NET and a good business model too.

    You have all the pieces for a success here. Finally something that can compete with Windows Sharepoint Services and ASP.NET – and you do not even have to use a J2EE Server!

    Competition is good.

    A word of advice. As soon as you can obtain proof that eXo really scales and can be deployed in web farms. The opposition, read Websphere, Weblogic, will do everything to discredit you in that area. Once this little matter has been taken care of (no problem I am sure) - nothing can stop you.

    Regards
    Rolf Tollerud
  12. Hello Rolf,

    May I ask you what you mean by : no Java “computer scientists” on the project?

    Thanks for your comments

    Benjamin
  13. Hello Benjamin,

    "no Java “computer scientists”" is a compliment coming from me.

    You have succeeded to gather a great team that is obvious, one can only read the excellent introduction - aimed at to help people really understand as opposed to convey at the reader how brilliant you are. Very refreshing and unusual!

    I am convinced that these types of systems eventually will replace the big "J2EE Servers".

    Regards
    Rolf Tollerud
  14. Many thanks.

    Indeed, we have mostly targeted the developpers community in our first article in order to build up our team. From the feedback that we got it became clear that the presentation was too technical for many users and clients.

    That is why, we are now trying to open our product to all the market actors and to adopt a more clear and less technical language (without letting down our first geek public :) )
  15. how about a JDOService ?
  16. There is actually no JDOService but indeed it should be quite easy to make one.

    Would you be interested to contribute?

    Regards
  17. how about a JDOService ?

    When you say "service", you surely don't mean a HTTP remoted persistence service. That's what an ordinary XML database already is.
  18. In the eXo platform namespace a service is an IoC type 3 component with an abstracted API (set of interfaces and value objects).

    You have the DatabaseService, the HibernateService and the CmsService (to talk on the persistent part). You could also have an XmlNativeDBService or a JDOService.

    In every case we abstract the functionnalities to create interfaces. Then we make an implementation. The simplest example is the LogService which is used by all the other services. We have a common API for it and a current implementation based on commons-logging. Moving to log4j or any other log library would be transparent to all the other services. And the beauty of IoC and eXo is that you just have to replace a jar (that contains the logging implementation) and all the services will use the new implementation with no modification in their code.

    The services are actually just POJO and interfaces. We are on the way to make them manageable by JMX, but also to expose them as Web Services. Therefore they will be accessible using HTTP (SOAP and WSDL).
  19. Orcale support?[ Go to top ]

    When is Oracle support planned?

    -Thanks
  20. Orcale support?[ Go to top ]

    Oracle 9 RDB support is almost done (in CVS).

    But you may be talking of the entire application server.

    If so there is no deadline, may be you would like to contribute on that port...
  21. Just as a db[ Go to top ]

    Not the app server...

    thanks for the info!
  22. Clustering[ Go to top ]

    Can I use CMS on one machine to update the content on a cluster of machines?