eXo Platform 1.0 OW RC3

eXo Platform 1.0 OW RC3 has been released and is available for testing.

This release includes some new - unique - features such as:

* the community concept, that allows to load portal template and navigation pages according to the group the users belongs too,
* the ability for the admin to load and modify any portal
configuration for any other user,
* new monitoring portlets including user navigation monitoring to allow analysis of user browsing behavior.
* enhanced forum and mail portlet, our development forum has finally been ported to that new portlet, we eat our own dog food :)"

Benjamin Mestrallet, lead of the eXo Platform (an ObjectWeb project), wrote:
"We need the help of the community to test that new release. It will be very very close to the 1.0 as we now have started the profiling and stress test phases.

See:
- http://forge.objectweb.org/forum/forum.php?forum_id=667
- http://exoplatform.objectweb.org

JORAM 4.2 RC1

Joram 4.2 RC1 provides new features as high-availability, dynamic configuration, and a lot of fixes and improvements.

    * High Availability Joram V4.2 provides the active replication of Joram servers and underlying agent servers, as well as replicated JORAM clients. It transparently handles network handover and server failover. This version currently relies on the use of JGroups.
    * Dynamic Configuration Joram V4.2 provide facilities to remotely add and remove Joram servers dynamically, using the Joram Administration API. This key feature, combined with upgraded JMX implementation, initiates a new set of management facilities for Joram.
    * Architecture and Performance improvements. Joram V4.2 provides a packaged version of a wide set of deep changes within the Joram and underlying bus architectures that lead to performance improvements compared to prior version V4.1. Communication protocols are concerned by this evolution, thus preventing backward compatibility with prior Joram versions."

See:
- http://www.objectweb.org/phorum/read.php?f=29&i=10182&t=10182
- http://joaram.objectweb.org

any ideas about support for context based urls per user so that it is possible to provide a hosting solution for a community whereby they can edit their own pages?

e.g
www.mysite.com/purdy for username purdy
www.mysite.com/drone for username drone

Any ideas anyone ?

Well....actually we released eXo Platform 1.0 RC OW 5 at the begin of this week and the new eclipse plugin that goes with it (with web unit test support to simulate a user browsing....we used that extensively for our stress tests).

Should go to 1.0 very very soon...

we used that extensively for our stress tests)

Just a note: eXo site still does not demonstrate stellar performance, especially when it comes to serving images.

Political reasons aside, it looks like from technology standpoint a portal like platform could be easier created with Tapestry components rather than Portlets. Could anybody share experience in this regard?

a portal like platform could be easier created with Tapestry components rather than Portlets

thats a question (if I understand it right) I have had in my mind for a while. Are there really so many customers that want a web site that consists of rectangular portlets that can be configured and assembled interactively? I find that, as sophisticated as this is, that it will not fit for most use cases. For a website that needs a fully customized (but not necessarily customizable) design, the "portlet paradigm" does not work well. Instead, a framework that provides/supports arbitrary UI components will be a better match.

christian

a portal like platform could be easier created with Tapestry components rather than Portlets

thats a question (if I understand it right) I have had in my mind for a while. Are there really so many customers that want a web site that consists of rectangular portlets that can be configured and assembled interactively? I find that, as sophisticated as this is, that it will not fit for most use cases. For a website that needs a fully customized (but not necessarily customizable) design, the "portlet paradigm" does not work well. Instead, a framework that provides/supports arbitrary UI components will be a better match.christian

Yes, you understood it right and expressed underlying thoughts well. IMO Tapestry suits very well for the purpose and I would like to hear from people who tried to get such thing done.

...Are there really so many customers that want a web site that consists of rectangular portlets that can be configured and assembled interactively? I find that, as sophisticated as this is, that it will not fit for most use cases. For a website that needs a fully customized (but not necessarily customizable) design, the "portlet paradigm" does not work well. Instead, a framework that provides/supports arbitrary UI components will be a better match

We're considering deploying eXo soon for an intranet portal. The driving factor for porlets was (1) we already do a lot of Java work and (2) we've got some new .NET development going on. The idea is that we could use the portal to aggregate web services and remote portlets.

But I do find portlets to be a rather heavy and overly complex framework. I'd rather just use a simplier CMS (java or PHP based) than a portal but I don't see how such a framework could be used to aggregate numerous existing applications without some serious customization. Anyone have some thoughts about this?

Political reasons aside, it looks like from technology standpoint a portal like platform could be easier created with Tapestry components rather than Portlets. Could anybody share experience in this regard?

I've seen portals/portlets built mostly so that management can say they built a portal.

On a similar note, I think RSS is a great technology and a lot of portlets could be replaced with a simple app that reads in rss feeds.

Indeed the term "Portal" often means both some "personalized home pages" (MyYahoo like) or just some content oriented web site (CMS oriented only, no dynamic portlets inside).

To avoid overkill, ideally you would need to only use the portal layer for "dynamic parts" which requires some kind of heavy business logic (not just some kind of basic scriptlets) and use some CMS oriented templates and predefined UI (more easy to handle than portlets) for static content. So the objective would be to have a CMS layer strongly integrated with a Portal layer so that the developer can call both API simultaneously on the same web page (and to avoid having to use two different servers).

That's the approach we used for the last 5 years.

Cheers,
Stephane

- -- ---
www.jahia.org : A Collaborative Source CMS and Portal Server