Discussions

News: Exo : New Open Source JSR 168 Compliant Portal and More

  1. The eXo platform is a powerful Open Source - JSR 168 compliant - enterprise portal built from several modules.
    Exo is based on innovative tools, APIs and frameworks such as JavaServer Faces, Pico Container, JbossMX and AspectJ.

    Subsystems include:

    Content Management System
    This module is built using the composite pattern as described in the now famous GoF book. The well known Object Oriented design has been enhanced with AOP (AspectJ) to provide a cached and indexed web file system. Aspects such as versioning, locking and webdav are on the way. Of course, we will implement the JSR 170 as soon as it is out.

    Portlet Container
    This eXo platform component can be used by any Portal provider. Its goal is to manage the portlet's lifecycle as well as to interact with JSR 168 compatible portlets. The module is based on the Pico Container that is a new but already well-known IoC3 lightweight container. It is bundled with Tomcat but a Jetty version has also been tested in order to provide portlets hot deployed as web applications. The portlet container interact with the CMS module to implement the persistent part required in the portlet API specifications.

    Portal
    Our portal is based on Java Server Faces(JSR-127) that is a new web framework paradigm. It provides a real MVC reference architecture allowing developers deal with components and events on the web layer almost in the same way as they would do on rich Swing clients. The portal interacts with the container, described above, so as to get the portlet contents and to retrieve users' preferences with the CMS AOP. Have also a look at our layout and skin management. It is worth the trip.

    Hot deployable services
    This module allows portlet developers to use and build easily any kind of services. The hot deployment feature is based on JbossMX, while the dependencies resolution is provided by Pico Container. Bringing together all these modules gives a lightweight hot deployable services container.

    The portlet Framework
    We provide a portlet framework à la Struts. It offers to portlet developers the possibility to manage all action mappings of all portlet modes in a single XML file. The latter also includes exception handling and dynamic action classes.

    Customisation
    The portlet provides a WYSIWYG customisation tool that allows your admin to build your site from scratch. We are very proud of this tool.

    Workflow service
    The workflow service is provided via a basic workflow portlet that we created. This service is built on jBPM - a very well thought open source workflow engine. Moreover, the eXo development team has good connections with Tom Baens and his team.

    Enhanced communication tools
    The eXo Platform allows exchanges of information that has its own structure. Imagine that you are a math teacher that wants to make a real time on line course. To be efficient, you need to send math formulas, but it is rather annoying to write sum(int(x,dx,a,b),i=0,n) or any similar syntax. The chat tool has been imagined to solve such problems. By developing a math plug-in, you can send structured messages to the talk room and integrate some dynamic content into your text. This will work exactly like when you add formulas in any text editor. What is important to understand is that a formula, or any kind of object, is not represented by an image but by a model structure, the latter helping to create the view. This model may be exchanged in an XML format, such as MathML or CML, for math and chemical objects respectively. This specialised content is not limited to any scientific field. The platform can be used by any type of community. For example, football and financial plug-ins can be developed.

    Last but not least
    The eXo platform comes with a bunch of portlets. One of the great advantages of this new standard lies in the fact that you can built your own portal upon Java Server Faces and use Velocity or Cocoon for portlets. Guess what, we provide Velocity and Cocoon integration portlets. To illlustrate this new concept, we included in the plateform show site the Sun sample portlets. They work perfectly well with our platform.

    Go to EXO's home: http://exo.sourceforge.net

    Here is a pdf introduction:
    http://exo.sourceforge.net/exo-docs/exo-document.pdf

    Threaded Messages (27)

  2. I stopped looking at the project at the moment i saw the license. they should really switch to bsd.
  3. Hi Christoph,

    I don't get your point, can you explain why you think it is unsuable why the BSD licence should be better.

    By the way, it is not a reason not to look at it, you may learn interesting things...

    Regards
  4. umm, on the sourceforge site i saw that its gpl. on the project homepage you state its lgpl, which would be much better. i will definately check it out when i find the time. Always happy to learn interesting things :)
  5. Hi Christoph,

    >
    > I don't get your point, can you explain why you think it is unsuable why the BSD licence should be better.
    >
    > By the way, it is not a reason not to look at it, you may learn interesting things...
    >
    > Regards

    GPL is good if you're going the MySQL route. GPL everything and dual license it to a different non-GPL license, but you have to pay for it.

    LGPL is probably the best license for the type of open-source software you're shipping. JBoss uses LGPL, so that we guarantee that our project remains open-source, yet the license is lenient enough so that JBoss can be embedded in ISV distributions.

    Unless you're going the MySQL route, I recommend LGPL as it gives your project the best protection, yet is open enough for embeddability. Don't let anyone on this board let convince you that LGPL hurts adoption. It is just not true, and JBoss is a point in case for that.

    BSD and ASL licenses just open you up to be screwed by companies that want to steal your work. That is just my humble opinion.

    Bill
  6. LGPL == best of both worlds[ Go to top ]

    Well done bill.

    LGPL/GPL are more business friendly and developer friendly than BSD style ones that only serve the purposes of a few vendors.

    BSD style license do not require that extension to the server itself be put back. so a VENDOR can take your stuff add a red button on top of it and call it "enterprise bla bla/with red button". Charge for it and not give back anything (money or code). You (benjamin mestrallet) don't benefit from that, period. The BUSINESS user, say an ISV, will pay for that software he doesn't benefit from that either. only the vendor benefits in that scenario.

    BSD == DEVELOPER UNFRIENDLY, VENDOR FRIENDLY, BUSINESS UNFRIENDLY

    LGLP style license on the other hand allows you as an open source professional to build software that requires vendors to give back and LGPL. That means that you will stay in control of your software, you will be protected. It was in our experience at jboss. Also the business user is protected since the LGPL says that the software is and will remain free, jboss will always be free. BEA can't take it and charge for it for example.

    In short benjamin, if you are professionaly serious (in the professional open source sense) about your framework here you must make sure it remains LGPL as it will enable you to make a living at it, as opposed to the first big vendor that will take it.

    LGPL == DEVELOPER FRIENDLY, VENDOR UNFRIENDLY, USER FRIENDLY

    Finally the history of FreeSoftware shows that the most succesful examples of open source businesses are all under Free Software foundation licenses (Linux, JBoss, MySQL) with linux and MySQL under the stronger GPL actually. So don't let clowns talk you out of anything ( I let clowns talk me out of the GPL in my days).

    On the project, I think the jmx+aop+ioc is a sound foundation for a portal project and would like to see that infrastructure in jb4, with only ioc missing right now. We are exploring that avenue so is spring, they are relevant directions. Pico is good in its non-intrusive approach, maybe you can share insights as to why you went the way you went?. I wish you all the succes so we can integrate your stuff if it works ;)
  7. LGPL == best of both worlds[ Go to top ]

    You seem to have several misconceptions about open source licenses, which is rather surprising.

    One of the top two open source projects in the world is the Apache web server - with a BSD style license. I've yet to find the person who said Apache was either "developer unfriendly" or "business unfriendly". In fact, along with Linux it's the most successful open source project in existence.

    You say "You (benjamin mestrallet) don't benefit from that, period. The BUSINESS user, say an ISV, will pay for that software he doesn't benefit from that either. only the vendor benefits in that scenario."

    The implication here seems to be that the creator and copyright holder of a BSD-style-licensed work somehow loses something if someone takes their work and does something with it without publishing the source. In fact, the original author loses nothing - the code is still theirs, but they are allowing a much wider audience to benefit from it as well as themselves.

    And in realistic terms, someone who attempts to sell "enterprise bla bla/with red button" is going to make a rather poor economic showing, given that the original "enterprise bla bla" is freely available. Anyone can download "enterprise bla bla" and add their own "red button" free of charge.

    And speaking of Linux, Redhat Enterprise Linux AS "Standard Edition" costs $1,499, "Premium Edition" costs $2,499.

    Of course, source is available, and the term "derived work" is rather muddied when you're talking about a huge Linux distribution, and most of what you're really paying for is various support services.

    Last, a vendor like Red Hat can take JBoss as a big bundle, bundle it up with other stuff (hmm, like a Linux distribution), and sell it. The cost has to be "reasonable" (whatever that means), but you can easily sell a linux distro with JBoss built in for, say, $50, without violating the LGPL. So, in fact,
    other people can make money off JBoss (for instance) with the JBoss owners getting zero benefit out of it.

    "Finally the history of FreeSoftware shows that the most succesful examples of open source businesses are all under Free Software foundation licenses (Linux, JBoss, MySQL) with linux and MySQL under the stronger GPL actually. So don't let clowns talk you out of anything ( I let clowns talk me out of the GPL in my days)."

    Yes - these business sell business and services on free software without a dollar of it going back to the original copyright holder. The only difference is that they have to publish their source code. In fact - you say that a GPL style license is "vendor unfriendly", and now you're saying (to paraphrase) "look at all these people making money off of GPL software". In case you didn't realize, the bulk of the various Red Hat distribution is not written by Red Hat employees. In fact, they've effectively hijacked Linux and built a business around it.

    And many businesses are making money off of BSD software too, or have even centered their business around BSD software. In either case, LGPL or BSD, you can make a business. The only question is whether you're forced to publish your source or not. And certainly I don't think IBM believes Apache is "business unfriendly", nor do the literally hundreds of thousands of web sites which run on Apache.

    In fact - IBM makes money off of both Linux and Apache, in droves. And none of that money goes back to the original copyright holders. How do you reconcile that with your statements?

        -Mike
  8. First of all, the licence will be either GPL or LGPL depending on components and containers.

    Thanks Marc to talk about the project... and I think I understand quite well why you are interested in :)

    >On the project, I think the jmx+aop+ioc is a sound foundation for a portal >project and would like to see that infrastructure in jb4, with only ioc >missing right now.

    The JBoss distribution we use bundled with eXo is JB4 with the new deployers interfaces. Those are used to provide portlets hot deployment as well as service deployment. So basically we have already jmx+aop+ioc in jb4, good for you no :).

    >We are exploring that avenue so is spring, they are relevant directions. >Pico is good in its non-intrusive approach, maybe you can share insights as >to why you went the way you went?.

    The IoC approch is much less intrusive than the services archives that are actually in the JBoss MicroKernel. Just create a POJO service, distribute it in a .es (exo service) archive (with a very tiny XML to tell the service name and the associated class). Then the service is deployed, added to the service manager built upon pico container (which resolve dependancies). In the portlet (or any other class), just call :

    ServiceManager.getInstance().getService(serviceName),

    cast the returned object to the correct interface (which is possible in a Unified class loading environement) and you can use the service.
    Later if you want to provide a new implementation for the service, just deploy another .es archive (using the same service name) and this is this new service that will be used in the portlet without any change in that class. You do not need any factory and you can that way define several configuration of services in an ant script, that means at build time.

    >I wish you all the succes so we can integrate your stuff if it works ;)
    Merci.
    The eXo portal add the services hot deployment feature a la JBoss Nukes but in a standard way (JSF, JSR 168) and with less intrusive code.

    Another good point is that any kind of rendering technology can be used in portlets from simple jsp, JSF, cocoon (XSL/XSLT), velocity to even PHP or any scripting language in embded IFrame.

    To be simple :
    JBoss + eXo + BPM portlet ( a workflow service based on JBPM will be available soon ) = real enterprise component stack.... but Open Source.
    This is the way to go to compete with big majors.

    Last thing, ther is an online demo..... so it works :)
  9. Benjamin,

    You list this code snippet:

    ServiceManager.getInstance().getService(serviceName)

    Isn't this the exact opposite of what you want with IoC? You shouldn't be looking up services, they should be provided automatically. IoC isn't just another registry service...
  10. Jason,

    The service manager is itself a IoC container of type 3 as it is based on pico container : the services do not resolve their depencies themselves. Inside the service container there is no lookup and the needed services are obtained through constructors inside the service components. This is this container that is a stict type 3 IoC container (with the jboss features we can add some hot deployment that requires a XML conf file).

    Note also that avalon, which is an IoC framework of type 1, requires lookup :
    import org.apache.avalon.framework.*;

       public class Shop implements Serviceable, Configurable, Initializable {
        StockManager stockManager;

        String shopZipCode;

        public void service(org.apache.avalon.framework.ServiceManager sm) throws ServiceException {
            stockManager = (StockManager) sm.lookup("StockManager");
        }

        public void configure( final Configuration configuration ) throws ConfigurationException {

            shopZipCode = configuration.getChild( "zipcode" ).getValue();
        }
        public void initialize() {
            // all service()ing an config()ing done.
        }
    }


    The portlet itself may or may not be part of this container.
    In other words portlet can acquire services through constructors :

    public class PortletIoCComponent extends GenericPortlet {
        private StockQuoteService stockQuoteService;
        public PortletIoCComponent(StockQuoteService sqs) {
            stockQuoteService = sqs
        }
        ....
    }

    But we also have a portlet framework where there is only one portlet class (and most of our portlets are based on this framework) : ExoPortletFramework, that redirects the incoming request to the needed Action class according to an XML mapping file. In this action classes the lookup as described in the previous message is needed as for now we do not register the action class into the IoC container.
  11. The JBoss distribution we use bundled with eXo is JB4 with the new deployers interfaces. Those are used to provide portlets hot deployment as well as service deployment. So basically we have already jmx+aop+ioc in jb4, good for you no :).

    >

    it's got to be part of the distribution

    > The IoC approch is much less intrusive than the services archives that are actually in the JBoss MicroKernel. Just create a POJO service, distribute it in a .es (exo service) archive (with a very tiny XML to tell the service name and the associated class). Then the service is deployed, added to the service manager built upon pico container (which resolve dependancies). In the portlet (or any other class), just call :
    >
    > ServiceManager.getInstance().getService(serviceName),
    >
    > cast the returned object to the correct interface (which is possible in a Unified class loading environement) and you can use the service.
    >

    hmmmm, at this point you have added zip compared to the native sar format of jboss (including the interface lookup which is present in 3.0.0)

    I was more interested in the AUTOMATED dependency resolving and reference setting of a picocontainer for example. From my understanding you leverage the picontainer stuff. sar+pico would be the right way to build it.
      
    > Another good point is that any kind of rendering technology can be used in portlets from simple jsp, JSF, cocoon (XSL/XSLT), velocity to even PHP or any scripting language in embded IFrame.
    >

    Ok that part is new and specific to you stuff then? I don't know much about portals frankly but that seems innovative.
  12. hmmmm, at this point you have added zip compared to the native sar format of jboss (including the interface lookup which is present in 3.0.0)


    That's true, but the fact that we use pico let us use POJOs and therefore is much better than sar for many things like dependancies services resolving, test or code resuse.

    >From my understanding you leverage the picontainer stuff. sar+pico would be >the right way to build it.

    For SARs the dependencies have to be explecitely defined in jboss-service.xml. Pico is much better from this point of view. We have enhanced pico capabilities with JBoss sar (for hot deployment only) that is right.

    > I was more interested in the AUTOMATED dependency resolving and reference setting of a picocontainer for example.

    The question here is what for, rewrite the JBoss service micro kernel? I don't understand the difference between what you are looking for and what we are doing, can you be more precise.
  13. jetspeed 1.4[ Go to top ]

    I work with jetspeed 1.4 for few months and its API is far from JSR 168 compilant. Also I think jetspeed choose velocity and turbine as template engine and service engine are not a good choice. The platform should be more independent and flexible. Velocity is aesy to use and easy to learn, true. But you cannot build a powerful application without knowing java and jsp
  14. From my understanding you leverage the picontainer stuff. sar+pico would be >the right way to build it.

    >
    > For SARs the dependencies have to be explecitely defined in jboss-service.xml. Pico is much better from this point of view. We have enhanced pico capabilities with JBoss sar (for hot deployment only) that is right.
    >

    right, it's relevant work. Would you mind contributing that to JBoss so we would maintain the core parts? You point to useful infrastructure enhancements with the pojo dependency tracking.

    It seems to me you are really focusing on the JSF part and we would gladly evaluate a pojo dependency framework and make it 'production' grade so JBoss kernel (MX,AOP, IoC) maintain it and it is what you are really using for JSF.

    I personally was interested in the Spring approach, which is a variant of that. The aspectJ part we are not a big fans of the syntax for pointcuts (overkill imho) but it may be our personal distaste of compilation heavy approaches. Take it offline if you want.

    marcf
  15. Just to let you know, that the today release is a beta version.

    You can also download the PDF file at :
    http://prdownloads.sourceforge.net/exo/ExoPlatform.pdf?download

    Regards,
  16. Online demo[ Go to top ]

    You can see a demo of the portal and several skins at :
    http://tuan.dyndns.org/exo/faces/layout/blue-lagoon/portal.jsp
  17. Is the demo still available?[ Go to top ]

    You can see a demo of the portal and several skins at :

    > http://tuan.dyndns.org/exo/faces/layout/blue-lagoon/portal.jsp

    Is the demo app up? When I attempt to hit the above mentioned URL, I get "The requested resource (/faces/layout/blue-lagoon/portal.jsp) is not available."
  18. Is the demo still available?[ Go to top ]

    Yes but the URL has changed to :

    http://tuan.dyndns.org/exo/faces/public/layout/blue-lagoon/portal.jsp
  19. How do you compare ExoPortal 1.0, jetspeed 2.0 and Liferay portal 2.0?

    Julien Boidard
    BNP Paribas AM
  20. I will give my point of view which is eXo centric of course, i hope that people from the other projects can talk and ondependant users too.

    eXo vs Jetspeed2

    We do not know many things on jetspeed2 right now. The code has been added on the cvs two weeks ago but it is unusable because it is built upon an IBM portlet container called pluto (that is also suppose to be the reference implementation) that has not been released yet. Pluto may also not be close source. We have built the whole stack with the portlet container. The jetspeed team had access to the JCP process but could not talk. For me in that conditions it is not real Open Source, we don't know who or which brand control the project. Hope someone from jetspeed can clatify that. Up to now i can not say more as i did not see anything working, it would not be fair.

    eXo vs Lportal2

    This portal in its new version is also suppose to be JSR 168 compliant. The portlets are now compliant but the portal itself will need much more work to provide features like deployment of portlets applications in separate web archives (war) - actually all the portlets are in the same servlet context as the portal (you get hudge portlet.xml and struts.xml files) - as well as features like PortletDispatcher. Up to now liferay portal was simply distribute in an enterprise archive (ear) which let it be deployed in most J2EE application server which was a good point. But the JSR 168 requirements will not allow that anymore and they will need to be tied to a servlet engine like tomcat.

    The biggest interest in LPortal is its set of portlets, Brian Chan (the lportal project leader) has done a real good and hard work to provide many portlets that are now jsr 168 compliant.

    My opinion is that you should use eXo as the portal and before creating your own portlets (if we do not provide them) have a look at lportal. We may also bundle lportal portlets in eXo quite quick ... hope Brian will help us:)
  21. Liferay and eXo[ Go to top ]

    I got to check out eXo last night and have to say I'm quite impressed. I like their architecture in how they make use of JBoss's JMX. Their support for Java Server Faces and for a lot of scripting is better than Liferay's.

    One of Liferay's goals is to provide not only the basic portlet container, but to also provide a rich set of JSR 168 portlets like email, calendar, message boareds (forums). These could later be used by eXo as well to provide users with even more bang for your buck ($0 in this case).

    I think overall this is great for the open source community as it will only serve to present more options to users. Good job eXo!
  22. Liferay and eXo[ Go to top ]

    Thanks a lot Brian,

    We really want to use many of your portlets, and you are right the only winner in that is the community.

    Also have a look at our portlet framework, it should help you a lot in the portlets development. It is inspired from Struts and as I know you use it, it should be quite easy for you to leverage it.
  23. JBOSS coupling[ Go to top ]

    Hi Benjamin,

    I´ve downloaded your portal and it looks really interesting because of the support of standards.
    But there´s one thing that makes me nervous. You seem to be coupled to JBOSS quite strong. So, how strong is this coupling? Is it possible to deploy your portal also on other application servers, maybe just Tomcat without big effort?
  24. JBOSS coupling[ Go to top ]

    Helmut,

    We plan to support many platform, as long as the platform has JMX and a deployer. All of our modules are independant except ExoDeployers module. You need to write a deployer for each platform
  25. JBOSS coupling[ Go to top ]

    Also, I am able to run exo only with JbossMX + tomcat + logging service. It is actually the tomcat only. The whole package is less than 10M. But I think for a portal, you need much more than that.

    The first deployer we wrote is in june and it is for JB3.2.1 and jetty webserver. Then we move to JB4 , write new deployer for tomcat. I hope we will have some time to update the deployer for Jetty as well
  26. Hi guys,

    The title said it all ! Do you have any plan for that ? with say ... mvnforum ?

    thanks
  27. integration with a forum package[ Go to top ]

    I am thinking about that. Actually , I already have a basic forum and mail portlet that I write long time ago, it work with the old API (Websphere API). But I prefer to have a third party or some one join the group to maintain that. We have too much of work now.

    For mvnforum integration, I think the only way to integrate is to write a HttpRequest wrapper to encode and decode the request. We did it with Cocoon and it work. But it is not a nice way to intergrate :-(. If mvnforum has a controller like strut. It will be much esier to rewrite and integrate
  28. Where can I get ServiceManager[ Go to top ]

    Hi, Benjamin

    Where can I get ServiceManager?

    I entend to use portlet in a business process manager (BPELPower: http://bpel.laits.gmu.edu). When deploying sample project in Tomacat, I got folowing message. Could you let me know where I can get class Servicemanager?

    Thanks

    Jonas

    -----------------
    [/portlet]Exception sending context initialized event to listener instance of class exo.services.portletcontainer.impl.servlet.PortletApplicationListener
    java.lang.NoClassDefFoundError: exo/services/ServicesManager
    at exo.services.portletcontainer.impl.servlet.PortletApplicationListener.contextInitialized(PortletApplicationListener.java:49)
    at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3827)
    at org.apache.catalina.core.StandardContext.start(StandardContext.java:4343)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:823)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:595)
    at org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:277)
    at org.apache.catalina.core.StandardHost.install(StandardHost.java:832)
    at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:701)
    at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:432)
    at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1083)
    at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:327)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
    at org.apache.catalina.core.StandardHost.backgroundProcess(StandardHost.java:800)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1619)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1628)
    at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1608)
    at java.lang.Thread.run(Thread.java:536)