Ask TSS: Do any Java CMS/Portals match the PHP ones?

Discussions

News: Ask TSS: Do any Java CMS/Portals match the PHP ones?

  1. After reviewing many of the Portal/CMS options out there, Java communities Indicthreads.com and Javalobby.com have both concluded that PHP-based alternatives are better choices than existing open source Java-based systems.

    Indian Java portal Indicthreads.com analyzed a number of options prior to their launch from an ease of use, hosting, size, and other alternatives and concluded that PHP CMS' are a better choice than the Java ones.

    Even JavaLobby.com is making similar conclusions, according to their most recent newsletter:
    Is there any Java package that does what this PHP package does?
    We have a couple of new sites in development for the Javalobby network, and we have been facing the tough question of whether or not to use Java to build them? After long consideration we're close to deciding not to, at least not for the main core of the sites. Instead, we're thinking we may try out the powerful PHP content management system called Drupal. As far as we know there's nothing quite like this in the Java space, and the effort required to implement the features Drupal offers by default would take us a long time to develop in Java. It just doesn't make sense to start from scratch when there's an active community already growing around Drupal. We have looked at JetNuke, JBoss Portal, and several other Java-powered options, but as far as we can tell they are not superior for our purpose.
    There are a large number of Java-based Portal/CMS systems now, surely some must be better than the PHP ones? Are they really better or is this a problem of perception? Is Java in catch-up mode and will JSR's 168 & 170 help us soon surpass the PHP versions?

    Editors Addendum:
    Indicthreads and Javalobby both only looked at open source CMS. The intent of this thread is to look at all solutions, commercial or open source, in hopes of identifying better solutions in Java or at least figuring out what we need to get there.

    Threaded Messages (90)

  2. PHP vs. Java CMS/Portal[ Go to top ]

    This is a prime example of how Java developers need constantly to look outside the Java world to see how to improve their products and their expectations for those products. The power of PHP is its lower barrier of entry – more developers can more quickly get to creating the functionality they are really excited about developing. This directly leads to more feature-packed solutions like those mentioned here hitting the market and evolving with greater agility.

    That being said, Java as a platform and the products built on it do retain its principal advantages – enterprise robustness, platform independence, and adherence to standards. The emerging JSR-170 specification will direct the evolution of CMS products across the field, ensuring (at least in theory) that most of the efforts being put into various CMS solution will retain interoperability. When the Java CMS market matures, there will be a rich diversity of CMS-related applications from which to choose, each being able to complement the others to offer best-of-breed CMS solutions. And they’ll plug into existing Java applications more seamlessly than a separate PHP solution. This should not be too far off on the horizon. In the portal / portlet space, we’re already seeing how JSR-168 is reaping benefits in standardized, mature, and robust portal and portlet products such as Liferay.

    The reality is these PHP applications are valuable to the Java development community; they can be seen as trailblazers in the CMS space from which Java developers can glean principles and ideas for better developing their own offerings.
  3. Python has the best one[ Go to top ]

    Maybe not the most choice but Plone/Zope is pretty hard to beat.

    I evaluated Drupal too but I have a hard time taking anything written in PHP seriously, like Perl I just don't think it scales well. While Drupal has a lot of neat plug-ins Plone seems to do the CMS part better IMO.

    Plone major drawback has been it's documentation but the last six months or so have it blossom with several new books and a better job, by the community, to organize coherent documentation that eases the learning curve.
  4. Python has the best one[ Go to top ]

    Maybe not the most choices but Plone/Zope is pretty hard to beat.

    I evaluated Drupal too but I have a hard time taking anything written in PHP seriously, like Perl I just don't think it scales well. While Drupal has a lot of neat plug-ins Plone seems to do the CMS part better IMO.

    Plone's major drawback has been it's documentation but the last six months or so have it blossom with several new books and a better job, by the community, to organize coherent documentation that eases the learning curve.

    Interestingly, I use Plone as a intranet to report on all of my build and deploy activities for J2EE apps on WebSphere. A sort of Product Data Management or System Configuration Management. I tag news items with metadata with project, build and promotion data so it can dynamicly populate dashboards for a given environment and/or product. We also use Wikis to document operational data and to build deployment plans as we go. We also have a ticketing system for demand management. I'm sure most CMS systems can do this and more but for me, it was by far the easiest to install and get running.

    Other than the inciting title this is not flame bait. I am just suggesting that if the Java is going to look outside, don't just look to the PHP community.
  5. The Plone/Zope content management system is based on python, boasts an object database that is easy to master and develop with, and has plugins to enable direct-from-UML class creation in a very short time.

    If you are looking at PHP based CMSs, you need to at least glance at Plone/Zope. In our opinion, and in the eyes of our clients, it's a more credible solution, and very productive.

    Plone was originally seen as a thin skin on top of Zope (although it was more that this), but it has now evolved into a powerful system with many add-on "Products" (not necessarily in the commercial sense") for many real-world applications. The Plone/Zope stack out-of-the-box is internationalized, localized, allows multilingual content, graceful, workflowed content translation, has undo features, powerful role-based security, group management, can be integrated with LDAP, RDBMS, and lots more: Browser-based; Workflow; Support for load-balancing; Apache/Squid support; Cache-consistency (ZEO); Graceful upgrades with no downtime; Progressive backups; Total redundancy. And I've missed quite a bit!

    If you need a project completed in one week or one month, with low risk, Plone is a very practical solution. Totally Open-Source.
    http://plone.org
    http://zope.org
    http://python.org

    We entered the CMS space using Java, J2EE, JDO, JSP, etc. in 2002. Since then our productivity has been much higher with Plone. It is not for everyone, and there is clearly a learning curve for a pure-Java shop, but the really big deal is that you can hit the deck running, and the community is incredibly supportive.

    Best wishes in your CMS decisions.

    Check this out: http://plone.org/about/sites/
  6. J2EE/PHP XML-based CMS[ Go to top ]

    Hi to all.

    This is a bit off-topic, so excuse me in advance.

    For a project I need to find a CMS (possibly an Open Source one) which enables me to import (or insert) content structures and content instances defined by XML files (XML schema for the structure and XML file for content instance) or better directly import HTML code.
    This CMS should also be able to use XML/XSL templates for defining pages strutures and to export data in XML format.

    Is there an Open Source CMS, either J2EE or PHP based that offers this or part of this, or at least a similar working mechanism ?


    Thank in advance to anyone who helps in this.


    Davide
  7. J2EE/PHP XML-based CMS[ Go to top ]

    Hi to all.This is a bit off-topic, so excuse me in advance.For a project I need to find a CMS (possibly an Open Source one) which enables me to import (or insert) content structures and content instances defined by XML files (XML schema for the structure and XML file for content instance) or better directly import HTML code.This CMS should also be able to use XML/XSL templates for defining pages strutures and to export data in XML format.Is there an Open Source CMS, either J2EE or PHP based that offers this or part of this, or at least a similar working mechanism ?Thank in advance to anyone who helps in this.Davide

    there is. Apache Lenya
  8. PHP is ahead[ Go to top ]

    Last year I was researching CMS systems for fun and my conclusion after a month is that PHP CMS is better today. I honestly don't know why that is so, but my gut tells me it is because they had a head start. I remember researching CMS tools back in 2000/2001 and there were already several tools in that category. Honestly, I see no point in duplicating or porting an existing CMS to java unless the goal is to improve it. Rather than waste a lot of time duplicating an existing PHP CMS, I much rather setup Apache and be done. my bias 2 cents.
  9. Matter of choice[ Go to top ]

    I too have had a look at both Java and PHP cms systems. Okay in private I use php based cms systems to build my home page and sites for my friends. With CMS systems such as MamboLite, Guppy and CMSimple one does not even need MySQL hosting. This makes hosting much cheaper. I have had a look at some Java CMS systems and found them to be generally more cumbersome to install (thats my opinion). OpenCMS appealed the most to me. My favourite though has to be MeshCMS. Simple, no DB required. Jast grab the .WAR file and place it in your webapps dir and you are in business. It doesn't have too many features which is great too. Oh I forgot to mention I do agree that php CMS systems are ahead of the Java systems, the reason I looked at the Java systems is because most of out enterprise applications are based on Java and thus we needed something we could integrate into our existing apps. We are still trying to make up out minds.
    Mpume
  10. Re: PHP is ahead...or is it?[ Go to top ]

    Last year I was researching CMS systems for fun and my conclusion after a month is that PHP CMS is better today. I honestly don't know why that is so, but my gut tells me it is because they had a head start. I remember researching CMS tools back in 2000/2001 and there were already several tools in that category. Honestly, I see no point in duplicating or porting an existing CMS to java unless the goal is to improve it. Rather than waste a lot of time duplicating an existing PHP CMS, I much rather setup Apache and be done. my bias 2 cents.

    I'm not sure if it's that they had a head start, but more of an incentive. If you look at who develops and uses php-based CMSs such as mambo, postnuke, and phpnuke there is an overwhelming number of web designers, which is why most php-based solutions have a better LAF then their Java counterparts. Most of these guys are (or were) on the forefront of building the world wide web.

    The down-side to the php solutions is that the code is horribly mangled and very hard to maintain. Although it's very easy to do something like:

    <code>
    $count=0;
    while ($row = $db->sql_fetchrow($db->sql_query("select id,title from content order by id desc")))
    {
        $id = $row['id'];
        $title = $row['title'];
        // Output them as HTML/links whatever
        $count++;
        if ($count == 10) { break; }
    }
    </code>

    You have to do it 1000 times which leads to code that is almost unmaintainable. Sure you can pick out which php file contains a query and change it, but if you ever want to make changes to the structure of the data get ready to go to refactoring-hell for a few days.

    On the flip-side most java-based solutions are developed by j2ee developers that know how to architect good enterprise class solutions...but don't necessarily know how to make it look good (although I think Magnolia has done a good job at this).

    I've done some small sites using mambo and postnuke, but in my opinion they will never be entrprise solutions. This is evidensed by the sheer number of modules/components that never make it past the alpha phase in any of the php-based solutions, while most of the Java-based solutions don't have the involvement to get to the vast number of modules/components to compete.

    That's my $.02.

    Regards,

    Thad Smith
  11. Re: PHP is ahead...or is it?[ Go to top ]

    I think you undervalued what PHP can do. I have an experience developed CMS for the biggest internet portal in Indonesia (more than 1 million hits & 600,000 registered users). We helped them moved from Vignette to taylor made CMS with PHP & MySQL, and it was done in a month with 5 programmers. Believe me, it's not like what you said, repeting SQL connection & query on 1000 pages. In PHP you can code as simple as you want or as complicated as what the application needs.

    regards
    farid
  12. java cms using subversion as a datastore[ Go to top ]

    Does anyone know a java cms that uses subversion as a data store instead of a database? I have seen some cms written in python and ruby doing that ..
  13. My own experience[ Go to top ]

    Hello.

    I am a Java developer and Java is the language I know best. I am also a teacher and I was looking for a LMS (Learning Management System, a.k.a "virtual campus"), that is a CMS with some learning management tools (grading, classroom groups, etc).

    A year ago, I was looking for a Java solution but I found very few. Even worse, the solutions I found lacked documentation, were too simple and very complex (see http://www.manageability.org/blog/stuff/open-source-learning-management-systems/view).

    I considered a simple CMS. I couldn't install Liferay (some odd JBoss error appeared though I followed instructions) and I couldn't make Exo work with MySQL. Even worse, both products didn't give me the tools I needed.

    I gave up. I began to look in PHP world. What a difference! A lot of products, very complete and easy to install. I finally chose Moodle and in a while I had a fully featured virtual campus running with all sorts of tools. A few days more and I managed to make the virtual campus look like my website (see http://aula.aurumsol.com). Easy and painless.

    (By the way, Moodle code is the worst I have seen in my whole career. Not only messes presentation with business logic but it is full of dirty design and programming. If you have a time take a look at www.moodle.org. But, at least, it works and has saved a lot of time and work).

    It is sad that Java has no such thing. I think the Java community don't put enough attention to have complete solutions that really work. When it comes to infraestructure (Web servers, persistence engines and so on) it is really great, but when it comes to complete solutions (CMS) it is really poor.

    Excuse for my English

    Vicent Palasi
  14. My own experience[ Go to top ]

    Hello.I am a Java developer and Java is the language I know best. I am also a teacher and I was looking for a LMS (Learning Management System, a.k.a "virtual campus"), that is a CMS with some learning management tools (grading, classroom groups, etc). A year ago, I was looking for a Java solution but I found very few. Even worse, the solutions I found lacked documentation, were too simple and very complex (see http://www.manageability.org/blog/stuff/open-source-learning-management-systems/view).I considered a simple CMS. I couldn't install Liferay (some odd JBoss error appeared though I followed instructions) and I couldn't make Exo work with MySQL. Even worse, both products didn't give me the tools I needed.I gave up. I began to look in PHP world. What a difference! A lot of products, very complete and easy to install. I finally chose Moodle and in a while I had a fully featured virtual campus running with all sorts of tools. A few days more and I managed to make the virtual campus look like my website (see http://aula.aurumsol.com). Easy and painless.(By the way, Moodle code is the worst I have seen in my whole career. Not only messes presentation with business logic but it is full of dirty design and programming. If you have a time take a look at www.moodle.org. But, at least, it works and has saved a lot of time and work).It is sad that Java has no such thing. I think the Java community don't put enough attention to have complete solutions that really work. When it comes to infraestructure (Web servers, persistence engines and so on) it is really great, but when it comes to complete solutions (CMS) it is really poor.Excuse for my EnglishVicent Palasi

    Vincent,

    Take a look at the Sakai project. It's a full blown LMS implemented in 100% Java, developed mainly by UMichigan, IndianaU, Stanford, and MIT. Sakai "tools" are written in JSF, with Spring providing application services and hibernate in the persistence layer. The current 1.5 release is about halfway between a complete refactoring of legacy code into the "2.0" platform. I'm surprised you were unable to find any info about it, as it's very high profile.

    Also, I'm surprised UPortal was not mentioned in this thread. It's probably the most popular portal platform among higher ed.

    -Dave
  15. Misleading title[ Go to top ]

    As I already commented on the original Indicthread entry the title is misleading. It should read "Do any OpenSource Java CMS/Portals match the OpenSource PHP ones?". Rather puzzling that you chose to ignore that little detail, but I suppose it makes for a catchier article.

    If people looking for CMS/portal solutions are only interested in OpenSource thingies, fine, but then state that clearly. In contrast, I am fairly sure that none of our customers would even consider using an OpenSource CMS, regardless of whether it is Java or PHP based. AFAIK there are none that are even close in terms of CMS/portal functionality. But that is of course a matter of priorities (e.g. money vs "getting the job done").
  16. disagree with that[ Go to top ]

    I cant follow the arguments of javalobby.com. I made my own research some time ago which you can read here.

    http://www.logemann.org/blojsom/blog/default/2004/11/21/mt_193.html

    I took the time back then to really install some of the well known PHP systems (not drupal) in order to see what they are capable of. I also checked the drupal docs a few minutes ago and its not convincing either. To me, NO CMS, whatever language written in, can in any way compete with the better professional packages available today. The only functional convincing OSS package was Typo3 but its usability and maintainability tends to zero.

    Marc
  17. In other words..[ Go to top ]

    if I understood your post correctly, you actually agreed with what I said (that OpenSource CMS's, regardless of implementation language, can't compete with commercial ones) even though your post title said "disagree with that".. right?
  18. Not java, nor PHP - Python !!![ Go to top ]

    OpenSource CMS's, regardless of implementation language, can't compete with commercial ones

    Well I can point to at least 1 OpenSource CMS that successfully competes with commercial ones.
    But is is not java nor PHP. It is based on Zope (Python).

    Plone.org

    I've been evaluating several CMS for our company, including java ones. And then we found plone. And we are happy with it.
    It is extremely easy to install and run out of the box (2 minutes). It is very easy to admin. and easy for end users. It has WYSIWYG editor, and supports WebDAV. It has lot's of third party products and plugins (spellcheckers, blogs, photo albums, wiki, calendars, skinz, IM, you name it.)
    It has several very good books, available on amazon.com
  19. open source CMS not scalable[ Go to top ]

    Tried my Hands on Open Source CMS tools!! But Didn't find them scalable to take billion hits pm . They are good enough for small set up but for commercial need ,we require the proper enterprise set up !!
  20. Forget PHP, try TCL![ Go to top ]

    From your post:
    So what is my conclusion? Commercial Software has an easy game in this area. I know at least 6 commercial CMS systems, outperforming any open source CMS by factor 3 in terms of functionality and design. So what will i do?
    [snip]
    <P>
    I'm only familiar with IBM's product (Portal Server I think), but I recall that you wrote TCL ("tickle") scripts. Anyway, they were making the switch to JSPs however.
  21. "Enterprise" is a loaded term[ Go to top ]

    I dunno; Java folks use the word "enterprise" to hide behind all too often. Fact is, some seriously high-volume sites are written in PERL or PHP and these sites are on the public internet serving WAY more people than some internal corporate portal.

    I think writing off PHP-like languages as toys is a mistake; they have real value, and there should be some way to apply the lessons learned to Java, to capitalize on both.

    The thing with PHP-like languages is that it's easy to use that it attracts people who aren't just coders, but people who have a specific feature in mind they want to see happen (whereas a lot of javaheads are all about making the most beautiful piece of code architecture and treat usability/interface as an afterthough. This site is a HUGE example of that). And a person who isn't a coder, but CAN write code is not going to want to read the patterns book and understand XXX-driven Architecture in order to run a SQL statement and show the results on a webpage.

    If you think about it, a PHP-driven site is actually implemented in two "scripting" languages: PHP for logic and SQL for data access. In java, you use Java for both, and java is HORRIBLE as a data access language (which is why we end up putting EJBQL in our deployment descriptors).
  22. Java as a data access language?[ Go to top ]

    If you think about it, a PHP-driven site is actually implemented in two "scripting" languages: PHP for logic and SQL for data access. In java, you use Java for both, and java is HORRIBLE as a data access language (which is why we end up putting EJBQL in our deployment descriptors).
    Huh? how in the world do you use java as a data access language? The DBMS I work with only understand SQL, and the only means that brings me closer to java/object semantics without losing the power of SQL is HQL (Hibernate Query Language), or maybe JDOQL for that matter.

    BTW, on the topic of PHP CMS vs Java: I think one difference is that the PHP world consists to a large part of kids that have had nothing but the web in mind for years, and work in a setting very different from the average (enterprise) java developer.

    christian
  23. As I already commented on the original Indicthread entry the title is misleading. It should read "Do any OpenSource Java CMS/Portals match the OpenSource PHP ones?". Rather puzzling that you chose to ignore that little detail, but I suppose it makes for a catchier article.

    That was by design - not for a catchy title, but because I hoped people would discuss commercial solutions here too, since the majority of companies out there will also consider commerical products too, and peoples perspectives there would be useful for others to read.
    AFAIK there are none that are even close in terms of CMS/portal functionality.

    That's useful for others to know. What are the featues that makes your solution better?

    Floyd
  24. Wrong question[ Go to top ]

    What are the featues that makes your solution better? Floyd
    Well, that's just it. Whether a CMS/portal is "good" or not is not mainly a technical problem, hence "features" are really not that important. One of the main problems I see with many OpenSource projects (in particular, but many commercial ones as well) is that they are "by programmers for programmers". I can count on one hand which of our customers actually have programmers, or even people that understand HTML/CSS to a decent degree, on staff.

    A CMS product (OpenSource or otherwise) of that kind is totally useless for such an organization. "Oh you can get it for free, but you have to hire a couple of developers/consultants to actually use it". And then it all of a sudden costs some serious money. So it's a bit like drugs: as new customer you get a free sample, and oh joy it is exciting and all that, but then you get the costs and hangovers.
  25. Open Source CMS[ Go to top ]

    I think, if you need a solution for a small or mid sized website only, or looking for a CMS on departement level, you are well of with OpenCMS or Zope/Plone.

    But if you are lookung for an enterprise level solution with advanced features like cross media distribution, content syndication, workflows, DRM and stuff, none of the Open Source solutions work well. Then you will need sth. like Interwoven Teamsite, Vignette Storyserver or CoreMedia.

    All this Mambo, Drupal, Midgard, Typo3 stuff just isn't really CMS.

    Andy Pahne
  26. Non opensource CMS solution[ Go to top ]

    Agreed with you !

    Do you know HummingBird solutions, ATG or Documentum !?
    Think they're very good solutions but ok, not opensource !
  27. It's just a royal pain compared to PHP (or equiv). Part of it is because of
    the dynamic/scripting nature of PHP, but a big part of it is that Java
    programmers tend to overengineer everything. Consider showing a list of
    content entry titles. In Java, you'd probably set up some
    DataContainers/JavaBeans, a big layer of abstraction to access the database,
    and a bunch of session beans to keep everything nice and separated. In PHP,
    you'd just (forgiving some syntax errors):

    <code>
    $count=0;
    while ($row = $db->sql_fetchrow($db->sql_query("select id,title from content order by id desc")))
    {
        $id = $row['id'];
        $title = $row['title'];
        // Output them as HTML/links whatever
        $count++;
        if ($count == 10) { break; }
    }
    </code>

    the PHP solutions won't result in the cleanest most maintainable code (phpNuke
    is a f**king mess), but it's really easy to implement, doesn't result in
    poorly performing code, and can allow you to implement lots of features
    quickly. Meanwhile, the Java guys are deciding how to implement the Abstract
    Factory pattern and writing XML configurations for PicoContainer....
  28. With Java it's just too much of a pain[ Go to top ]

    I still don't get why people compare Java to PHP, Perl, etc...

    What happened to use the right tool for the right job? If you are looking to implement a site that won't grow to enterprise size and complexity, than by all means use a scripting technology. The code snipped about works great, when you are looking to implement a quick and dirty solution, but the abstraction level provided by J2EE based technologies are truly the right way to go in an enterprise environment.

    I for example came from a heavy Perl environment years ago, and many in the Perl world seem to think that Perl can be used for everything, and in reality it can, but it's definitely not the right tool for everything. I love it's text parsing capabilities, etc..., and by all means you can implement an enterprise-grade system in it, but the frameworks, tools, etc... available to a java developer are by far superiour to any perl developer.

    Ilya
  29. Agreed on it[ Go to top ]

    the PHP solutions won't result in the cleanest most maintainable code (phpNukeis a f**king mess), but it's really easy to implement, doesn't result inpoorly performing code, and can allow you to implement lots of featuresquickly. Meanwhile, the Java guys are deciding how to implement the AbstractFactory pattern and writing XML configurations for PicoContainer....
    Completely agreed on it. But the problem many people do not understand is evolution. How fast new features can be implemented? How fast security bug might be fixed? Will it be another security issue arise after this bug fixed? How many copy&paste fragments I need to fix before I'll get all problems fixed?
    And at the end of the day - how much time developers will have to implement new features after they will fix all bugs?
    Does anybody thinking about such issues like:
    0. Modularization?
    1. Mantainability?
    2. Manageability?
    3. Scalability?
    4. Testing?
    I think 10 years of Computer Science research was meaningless for some (not all) PHP projects.
  30. Agreed on it[ Go to top ]

    1. Mantainability?2. Manageability?3. Scalability?4. Testing?I think 10 years of Computer Science research was meaningless for some (not all) PHP projects.

    About 4 months ago I started building a relatively large virtual society website using PHP (clubs, messaging, profiles, friendship, shopping etc). I was able to finish it in about 2 months and in less than a month I had a userbase of arround 40,000 users.

    Then I sold the website to a company and transfered the site to their Dual-Xeon server in less than 2 days.

    Their developers had 0 experience with PHP and MySQL but in 1 week they were able to start customizing website and adding modules etc. (after I a 3 hours php tutorial session). They have added something arround 10% to the original code in 1 week. They are able to find and correct normal bugs in less than 30 minutes.

    By the way website has 50,000 users now and 12000 users login every day and serves about 400,000 pages each day and server load is at 25% now.

    Perhaps our research results and directions are a little impractical or less practical.

    Mac
  31. Agreed on it[ Go to top ]

    Mac,

    What PHP CMS (if any) did you use for your site?

    Chris
  32. Agreed on it[ Go to top ]

    Chris, I developed everything myself. Actually I don not like messy code such as those in PhpNuke. I always try to have smallest, clearest html code in output to minimize load and creation time. regards,mac
  33. Using JSTL you can do the same, but real-world CMSes need to be heavily customized, and that solution would be real pain.
     Our experience with CMS is that Java ones are focused on large, commercial, feature rich things, while PHP ones are usually sticky to low-level, free, ones. There are bad and good things in each of the solutions.
     One sad thing to note is that since so many free PHP CMSes exist then community will not accept costly PHP feature-rich CMS's, on the long run this forces PHP developers to focus on other things (they need food too, and food is brought by money), and so PHP kills for itself
  34. I looked at this myself some time ago in the context of a planned project. We didn't want to build all the standard stuff ourselves (user management, virtual file system, forums, etc), so we were hoping to to find a good Java portal to integrate. It turned out to be harder than I'd thought. The main problems for us were these:

    * There's a huge number of Java Portal/CMS systems but relatively few good portlets. Once again, Java people turn out to be masters of infrastructure code but generally hate creating applications on top of it. The portlet spec should in theory have lead to a broad choice of pluggable services. So far, it has not.

    * The architecture of most portal frameworks is quite complicated and extremely volatile as everyone is working on JSR-170 integration. JSR-170 is an extremely central piece of architecture for a Portal/CMS, so basically everyone's doing the equivalent of a heart transplant, which is more or less visible on the user/API side. But this problem may be more of an issue for our particular project, because it's very data centric.

    * The whole security and user management stuff is under specified or the specs are not implemented widely. There's a huge number of different ways how people are doing it. Very few are using LDAP or they make it very hard to configure.

    * There is generally too little up-to-date documentation on all the interfaces. The portlet spec is not enough for deep integration particularily in those cases where JSR-170 wasn't there yet.
     
    * The portlet spec doesn't specify much in terms of templating/UI framework integration. Portlet frameworks are doing it very differently. Many start to do JSF but they all do it differently. However, I didn't dig very deep regarding this issie, so there might be a way to handle it properly.
  35. There are very good and matured Open Source Content management systems out there in the java world too. Out of all the ones, these are two that are fairly matured.

    1. Magnolia (http://www.magnolia.info)
    Magnolia is one of the best open source cms available in the java world. Magnolia is the first one to adopt JSR-170 specification. There is good documentation, support group and it's easy to use.

    2. OpenCMS (http://www.opencms.org)
    OpenCMS is out there for very long time and out of my experience it can be used for production systems. It has lot of features and very easy to install. Lot of documentation available and they are constantly improving the product.

    I haven't seen A product in opensource world which truly provides the portal and CMS capabilities. Jahia (jahia.org) is one of the system that provides but it is not truly an open source system.

    Probably some one can build the portlets for Magnolia and OpenCMS and integrate with either Gluecode or Liferay. That will be a great combination and can potentially give a tough competition to commercial products out there.

    -Rajender Sriramoju
  36. It Depends[ Go to top ]

    Portal technology has sometimes been misunderstood as a simple content management solution. If you're looking for just a portal with personalization, content editing, RSS support, and simple portlet, then sure the PHP-based portal are so much easier and better. Plus, the many supporters have developed cool themes/skins for the GUI as well. Portals like PHP-Nuke and Postnuke or any other PHP variances are all very good to relay web content to the users.

    However, I think the PHP Portals have shortfalls when it comes to application integration. To me, a full portal solution should include not only content management, but also ease of application integration. Try integrating some back-end mainframe systems using PHP. I bet that wouldn't be a 1-day task. Well, using most of the J2EE solutions, we all know that the J2EE platform supports so many different ways to integrate your current technologies, ranging from the infamous Web Services, to hundreds or thousands of J2CA adapters, we can easily integrate other existing apps into our enterprise architecture.

    If you're a small mom-and-pop shop in India, then surely you can use a PHP-CMS system. For an enterprise-level architecture, look no further than implementing a J2EE Portal Framework solution.
  37. Don't forget ATG Dynamo[ Go to top ]

    When I was researching CMS/Portal tools last year, 2004/03 ATG Dynamo looked very good. It is a complete solution. Very nicely packaged solution from database to presentation tier.
    It is Java, but not J2EE, JHTML is neat but non standard.

    It is easy to use, and one can build functioning portals very quickly.


    Checkout the review at TSS
    http://www.theserverside.com/reviews/thread.tss?thread_id=22567
  38. See below, but...[ Go to top ]

    I think you undervalue PHP-like languages by throwing them into "mom and pop"
    type analogy. It's just silly, because so many high-volume high-feature
    websites use those technologies. I almost had to laugh when you write:


    Try integrating some back-end mainframe systems using PHP. I bet that wouldn't be a 1-day task. Well, using most of the J2EE solutions, we all know that the J2EE platform supports so many different ways to integrate your current technologies, ranging from the infamous Web Services

    Such a task would take forever in J2EE as well! Fact is, web services,
    EJB marketplace and JCA have not materialized the off-the-shelf components
    that they promised, so you can't hide behind that to defend J2EE. Add to that
    that what OTS stuff is out there is hella expensive and it's a hard
    case to make.


    I dunno, I just wonder if anyone out there doesn't find JSP/Web Programming in
    Java completely painful? J2EE is great and EJB is certainly very powerful,
    but for content management/portals, it seems like overkill.
  39. PHP - "Mom and Pop" Usage[ Go to top ]

    I think you undervalue PHP-like languages by throwing them into "mom and pop"type analogy. It's just silly, because so many high-volume high-featurewebsites use those technologies.

    What high-volumne web sites are you referring to?

    If people use pure JSP (or Model-1) implementation, do you think Java will have lot of these "Mom and Pop" PHP-like CMS products?

    I think that the Java community already had enough experience to know that these Model-1 implementation (tighly couple codes, non-MVC pattern) would fail because of scaleability and maintenance issues, which only the internal team will know. Therefore, the Java community is started and continue to work on having better design, such as using MVC, IoC, AOP, etc.

    On the other hand, the PHP community may not have enough "software engineering" experience (notice I don't use the word "HTML/JS/SQL/Business Logic coding"). Most PHP developers are not software engineering; they are HTML/JS coders will a little knowledge of SQL.

    I bet if the Java community forgo any design and just develop the nice look&feel and features, Java will have as many so called "good" CMS as PHP.
  40. It Depends[ Go to top ]

    Try integrating some back-end mainframe systems using PHP.
    This is an example http://www.nse.lt/?lang=en, I am sure it is possible to find more.
  41. It Depends[ Go to top ]

    Portal technology has sometimes been misunderstood as a simple content management solution. If you're looking for just a portal with personalization, content editing, RSS support, and simple portlet, then sure the PHP-based portal are so much easier and better. Plus, the many supporters have developed cool themes/skins for the GUI as well.... Well, using most of the J2EE solutions, we all know that the J2EE platform supports so many different ways to integrate your current technologies, ranging from the infamous Web Services, to hundreds or thousands of J2CA adapters, we can easily integrate other existing apps into our enterprise architecture.If you're a small mom-and-pop shop in India, then surely you can use a PHP-CMS system. For an enterprise-level architecture, look no further than implementing a J2EE Portal Framework solution.
    +1
    you should consider www.jetnuke.org soon it will be a PHPNuke clone . and people who need a groupware can use it , ready to deploy.
    but when we talk about A portal System then its not about Groupwares , its about a Portal for some sophisticated business systems
  42. This one is for all you SENIOR ARCHITECTS who indulge in this sadistic ritual of writing bloody interfaces and abstract classes and call them JSR-XXX.

    Have you ever tried to build an application on the top of an JSR-168 portal container? If you have, you will know, how much fun that is.

    Well, for starters try sticking in a hot rod into a horse's ass, and you will understand what I mean.

    1. Neither the portal containers nor the portal spec provide a straight forward way to support "Separation of Concerns" or "Division of Labour". The MVC model of development is almost non-existent or is present, but in a very crooked manner. At least one portal container, Stringbeans acknowledges this, and have recently come up with something called an MVC portlet, that lets you build portlets on the top of their own mini-framework!

    2. With the lack of separation of concerns you end up needing a "Super Developer" who understands JSP,CSS,Servlets,Portal API, Portal Container API..., to implement even a simple portlet like an Order Entry Form. Needless to say, the drop in productivity is really astounding.

    3. Absolutely little or no tools support.

    4. The present portal containers are ok, when you want to pull a bunch of static or database driven data into a portlet, but try implementing a portlet that does a complete CRUD operation on your Business Objects, and you will know why portlet development is so slow and tedious.

    5. I am absolutely certain that none of the members on the portal spec team ever built a non-trivial jsp,servlet or php website in their life, and hence they never really understood that this API would end up being used by WEB DEVELOPERS. Web developers are tools people and generally adore things like Dreamweaver and Photoshop/Illustrator. Simply put for portal development the only tools you would have are VI or Windoze Notepad.

    6. When you develop a portal on top of any portal container you have put up with the container specific idiosyncrasies like themes support, which tends to make your portlets non-interoperable, when shifting portal containers. You would end up writing a lot of CSS and Image wiring code to ensure inter-operability.

    7. Apart from Liferay and the upcoming Jetspeed2 none of the portal containers have an pluggable authentication and authorization mechanism.

    8. Why are there no good Portlets available? Simple, because the developers who built these containers cannot eat their own dog food, as it smells like what else but, dog shit.

    I am a software developer working for a telecom product company in Calcutta, India, and we recently built an "Executive Dashboard" prototype based on Stringbeans. But I am sad to say that after spending about 1 month to get this up and running, and doing it successfully, I have concluded that I would build my on portal like API.

    Why am I re-inventing the wheel?
    Answer: Just to make sure, that I really do get a WHEEL and not an AXLE or something.
  43. really?[ Go to top ]

    7. Apart from Liferay and the upcoming Jetspeed2 none of the portal containers have an pluggable authentication and authorization mechanism.


    Are you just referring to the opensource portlet containers? If so, then fair enough. If not, then commercial portlet containers have been supporting this for some time.
  44. really?[ Go to top ]

    7. Apart from Liferay and the upcoming Jetspeed2 none of the portal containers have an pluggable authentication and authorization mechanism.
    Are you just referring to the opensource portlet containers? If so, then fair enough. If not, then commercial portlet containers have been supporting this for some time.

    Indeed. I worked on an implementation of SilverStream's portal server back in 2000/2001 and it had pluggable security, excellent content management system (completely configurable and extensible as should be expected of a first rate system), different output technologies, etc. etc.

    Can't blame Java for Novell killing the product...

    Even in its prerelease state (we started coding the system on a beta of the portal server) it was quite complete and usable.
  45. really?[ Go to top ]

    The SilverStream portal server is now part of Novell's eXtend product suite.

    I used to work for SilverStream during the glory days of the dot com boom and used the Portal Server quite extensively for a few high profile clients. I always believed that it was the stongest card in SilverStream's hand but most of the focus within the company was on their J2EE application server (which died a justifiable death) & their XML Web Services toolset.

    I still don't believe that anyone within Novell really understands how good their Portal product is/could be and it seems to be thrown into the mix as a giveaway with the eXtend suite. I guess the guys in sales & marketing find it difficult to demo & sell on it's own.
  46. really?[ Go to top ]

    The SilverStream portal server is now part of Novell's eXtend product suite.I used to work for SilverStream during the glory days of the dot com boom and used the Portal Server quite extensively for a few high profile clients. I always believed that it was the stongest card in SilverStream's hand but most of the focus within the company was on their J2EE application server (which died a justifiable death) &amp; their XML Web Services toolset.I still don't believe that anyone within Novell really understands how good their Portal product is/could be and it seems to be thrown into the mix as a giveaway with the eXtend suite. I guess the guys in sales &amp; marketing find it difficult to demo &amp; sell on it's own.

    Shame really. It was/is indeed a great product. Even the early betas we god were quite workable (despite the complete lack of documentation which sometimes drove us crazy, API docs which only list functions without explaining what they do etc.).
    We had some good guys out of the Dutch office (now closed) working with us who had a direct pipe to the US office.
    Someone must have thought us an important customer :)
  47. really?[ Go to top ]

    The SilverStream portal server is now part of Novell's eXtend product suite
    I don't know how it was at the time of Siverstream.
    I've played a bit with a demo version six months ago and I can tell you that, if it was good at the time of Silverstream, it's not anymore. I have to admit that the problems are more with the underlying application server than the portal server (it's also possible to use the portal server on Tomcat, Websphere and Weblogic). Novell says it complies to java standards, but after my tests, I really wonder how it got the J2EE certification: many things are proprietary and when you try to do them the standard way, they simply don't work. Just one example (amongst others): have you tried to get a remote interface for an EJB from a remote application ? The same code works from a client collocated on the server (like a servlet for example), but it doesn't work from a remote client (like a Swing app). Looking at the newsgroups on Novell, I wasn't the only one to have that problem. I've asked the question, but didn't get more help than the others.
    Also, it's really easy to crash the portal. It takes far too much resources (and time to reply) when processing a request. If you flood it a bit with too much requests, it crashes (and "too much" is not "that much": I've actually been able to crash it from a standard browser while being the only one connected to the server). I believe this is caused by the fact it uses XML everywhere (Novell should understand XML is not very good to access a database and to generate html pages). I'm sure that's why Novell has decided to move to JBoss. It's smarter than having to write a new application server to fix all the problems in the current one (but it's annoying for the customers who will have to migrate).
    I know I criticize it a lot, but it's also probably by far the most expensive solution on the market. For that price, you might expect a better quality.
  48. I am sorry you had those experiences with the product. I know first hand that it is a J2EE compliant application consisting of many loosely coupled subsystems. It was a pioneer in this space when it first came out. It encompassed a 168 compliant portlet container, content management, webdav, searching, security, user provisioning, directory, workflow and rule subsystems. While you can argue the various merits of some of these subsystems, they provided a very complete environment for the creation of a portal or other types of applications that could run over all the major data bases, and j2ee compliant application servers. We did have a weakness in the ejb area, but one thing that noone really knew was that the subsystems communicated to eachother through ejbs when located on seperate machines. Going even further, every aspect of the system could either be replaced with new implementations, or augmented with additional behaviours.

    When created many of the standards for these subsystems did not yet exist ( jsr170, jsr094, jsr168, etc ), and we were working very closely with on the various jsrs and oasis tc's to provide this level of standardization. Given that and some of the great technologies that were also added ( pageflows, xforms, dynamic portlet deployment,... ) I think it was a pretty successful solution. I always felt that it should be open sourced, as some of the plumbing was being replaced with more defact-standards from the open source arena.

    So, I would argue, that its openness, ability to run on bea, ibm, tomcat, silverstream, novell, jboss, as well as with ldap, databases, etc, gave it a very compelling story when competing against propriety solutions from some of the other vendors. To be honest, I have not seen this level of support or customization in the other portal offerings that have been mentioned.

    For clarity, I do not work for Novell. I used to (hint). I was the VP, R&D for exteNd Director, and personally designed many of the subsysems and the overall architecture. It is a much better product than many realize, and one that I am very proud to have been a part of.

    Jeff Broberg
  49. really?[ Go to top ]

    7. Apart from Liferay and the upcoming Jetspeed2 none of the portal containers have an pluggable authentication and authorization mechanism.
    Are you just referring to the opensource portlet containers? If so, then fair enough. If not, then commercial portlet containers have been supporting this for some time.

    care to give an example? I'm pretty skeptical, since "Proprietary Solution" and "Pluggable" don't rhyme in any language.
  50. 1. Neither the portal containers nor the portal spec provide a straight forward way to support "Separation of Concerns" or "Division of Labour". The MVC model of development is almost non-existent or is present, but in a very crooked manner. At least one portal container, Stringbeans acknowledges this, and have recently come up with something called an MVC portlet, that lets you build portlets on the top of their own mini-framework!
    The portlet API is a logical extension of the servlet API, where the service() method is broken up into processAction() for dealing with the HTML form data (and other 'actions' via URLs) and the render() method for producing the view. It appears to be an appropriate division of concerns for a controller and not anti-MVC. Admittedly, the API is pretty new (which is why PHP-portals are more feature rich), but most of the common web frameworks (e.g. Struts, Shale, Tapestry, WebWork) have said they would support the API. In addition, all the major open-source and commercial (IBM, BEA, Sun and Oracle) portals support running Struts and JSF apps in their JSR-168-compliant servers.
    3. Absolutely little or no tools support.
    What tools are you looking for? You can pay for portlet wizards in most commercial offerings, but you should be able to use an IDE with a remote debugger during portlet development, which is the only development tool I need.
    . . .When you develop a portal on top of any portal container you have put up with the container specific idiosyncrasies like themes support, which tends to make your portlets non-interoperable, when shifting portal containers. You would end up writing a lot of CSS and Image wiring code to ensure inter-operability.
    This is an issue. There are only a few common CSS classes in the JSR-168 spec driven by the WSRP spec (which most portal server support). WSRP 2.0 is due mid-year with new CSS classes.
  51. Who is using JSR-168???[ Go to top ]

    In addition, all the major open-source and commercial (IBM, BEA, Sun and Oracle) portals support running Struts and JSF apps in their JSR-168-compliant servers.

    Yes you are right, but all examples of JSF working seamlessly within Portal containers, do not go beyond the provervial "Hello World" example.

    If portal is mature enough, why are www.oracle.com, developerworks.ibm.com, java.sun.com, java.com, dev2dev.bea.com not using their JSR-168 portal containers to build these web infrastructure?
  52. If portal is mature enough, why are www.oracle.com, developerworks.ibm.com, java.sun.com, java.com, dev2dev.bea.com not using their JSR-168 portal containers to build these web infrastructure?

    Oracle advertises that their web site runs on their portal server (lower right hand corner of home page). IBM does not advertise it, but much on their content is tagged with a CSS class 'wpsPortletBody.' I can't tell if Sun and BEA web sites run on a portal server. Can you? There may not be a lot of Java portal server installations out there because the technology is relatively new. Still, there is a lot of activity in the JSR-168 space: observe the growing list of portal servers and very smart people like Rickard Oberg curently doing portal work.
  53. High Volume PHP Websites[ Go to top ]

    What high-volumne web sites are you referring to?

    Some examples;

    ---------------------
    Friendster.com
    Switched from Java to PHP to help scale.

    http://troutgirl.com/blog/index.php?/archives/22_Friendster_goes_PHP.html
    Alexa Rank 69 (that's of the whole Internet!) - http://www.alexa.com/data/details/?url=www.friendster.com

    ---------------------
    Yahoo.com
    All presentation logic is PHP
    http://www.radwin.org/michael/blog/2005/03/burton_group_report_on_pla.html
    http://www.radwin.org/michael/blog/2003/02/one_year_of_php_at_yahoo.html

    ---------------------
    Sourceforge.net
    Traffic rank 164: http://www.alexa.com/data/details/?url=www.sourceforge.net
    Open Source fork of Sourceforge code base has become "GForge": http://gforge.org/

    ---------------------
    Lufthansa.com (Germany's national airline)
    http://www.phpkitchen.com/index.php?/archives/361-Lufthansa.com-serves-6-Million-pages-daily-with-PHP.html
    Rank 3,915: http://www.alexa.com/data/details/?url=www.lufthansa.com

    ---------------------
    Sitepoint.com
    Grew their own CMS. Similar kind of site to TSS (articles / forums)
    Rank 924: http://www.alexa.com/data/details/?url=www.sitepoint.com

    ---------------------
    Flickr.com
    http://www.niallkennedy.com/blog/archives/2004/10/flickr_architec.html
    Rank 956: http://www.alexa.com/data/details/?url=www.flickr.com

    Bottom line is PHP offers "infinite" horizontal scalability to handle load because it's completely stateless. See http://www.oracle.com/technology/pub/articles/php_experts/rasmus_php.html

    ---------------------
    And there's more.

    The real myth that needs exploding, when consider Java and PHP, is there's no such thing as a generic software solution. Think about it.
  54. High Volume PHP Websites[ Go to top ]

    Bottom line is PHP offers "infinite" horizontal scalability to handle load because it's completely stateless.

    That's fine (actually, quite preferable) if the application has no state.

    What's even better is to use just Apache and make the whole site just a bunch of .html files .. it's hard to beat for scalability.

    Large web applications that do have state and transactions tend to use Java.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  55. ISP love you for that[ Go to top ]

    Bottom line is PHP offers "infinite" horizontal scalability to handle load because it's completely stateless.
    That's fine (actually, quite preferable) if the application has no state.What's even better is to use just Apache and make the whole site just a bunch of .html files .. it's hard to beat for scalability.Large web applications that do have state and transactions tend to use Java.
    Peace,
    Cameron Purdy Tangosol, Inc.Coherence: Cluster your POJOs!

    I love it when people claim "infinite horizontal scalability". Anyone that has had to call up an ISP to get quotes, and deploy a large number of servers will tell you there's no such thing. It's only infinitely scalable horizontally if you rent a bunch of empty rackspace. What happens when you need to add 10 more servers and the ISP is full?

    How long is it going to take you to find a new ISP, move all the servers and get them setup? If you do what google does, you rent a room, so that you can roll in your own rack on wheels. But even then it's weeks to get that going. Not hours or days. This myth has been going for over a decade now. People should realize that model only works if you keep a close eye on the traffic, system load, growth projections and plan very carefully.

    If you don't do all of those steps, it's not scalable. At best it means your website hobbles for a few months while you scramble to get new systems, and set it up. Even after you get 20 systems setup, a few of them will have hardware problems within in the first 6 months. That means you have to be prepared to go out and replace bad powersource, memory, hard drive or CPU. Diagnosing the problem isn't easy, so it's going to take 3-8 months for those new systems to stabilize. Frankly, if scalability matters and I need to be able to handle a 3x increase in traffic, I'll choose Java over PHP any day. Plus, you get the advantage of mature products like coherence, gigaspaces and so on.

    peter
  56. RE: ISP love you for that[ Go to top ]

    That's fine (actually, quite preferable) if the application has no state. [...] Large web applications that do have state and transactions tend to use Java.

    Would hazard to say large web applications that have state use technologies that support them, such as Oracle or these days even MySQL (despite MySQL being barely a database in SQL terms, until recently, performance / replication is does do well). Someone's going to response "but the DB is the bottleneck!" but that's just what they're teaching in class - reality is DB vendors have put a lot of effort into solving this.
    I love it when people claim "infinite horizontal scalability".

    Anyone that has had to call up an ISP to get quotes, and deploy a large number of servers will tell you there's no such thing. It's only infinitely scalable horizontally if you rent a bunch of empty rackspace.

    You may find this interview an interesting read: http://www.big-boards.com/int.php?n=60 . What's fascinating about this story is Derek Liu had no training as a developer, although he did have a background in networks. Basically he just used his brain and dealt with the problems as he encountered them. With PHP and MySQL there was never a "melt down" into out of memory exceptions. Performance just degraded as load increased. But Derek _was_ able to scale horizontally. The forum software he used, phpBB, most definately does use state but uses PHP's native session handling API. With that configuration and state related data stored in MySQL, load balancing could be implemented as simply as "round robin" DNS - not even a front end load balancer. His website, gaiaonline.com, it now ranked 2019 according to Alexa (http://www.alexa.com/data/details/?url=www.gaiaonline.com). Derek probably knows more now about scaling web applications than the majority of consultants working in the field.

    Otherwise suggest you read this: http://www.schlossnagle.org/~george/blog/archives/269_Why_PHP_Scales__A_Cranky_Snarky_Answer.html
  57. RE: ISP love you for that[ Go to top ]

    Otherwise suggest you read this: http://www.schlossnagle.org/~george/blog/archives/269_Why_PHP_Scales__A_Cranky_Snarky_Answer.html

    It's a good article, and he's right that the language itself is not a big factor in scalable performance.

    He does have a bit of a chip on his shoulder about Java .. but you can probably chalk that up to insecurity. For example:
    I am (pretty obviously) not a Java proponent. I don't want to malign a whole segment of developers, but the prevailing attitude I hear from that camp is 'my software scales because Java is a fast compiled language.'

    I've never heard anyone say that Java scales because it compiles. Maybe someone he knows said that, but it's a bit of a straw man in my book.

    The point about applications with state benefiting from Java is that there are a number of good solutions in Java for dealing with those problems. If you don't have the state problem, then one of Java's major advantages is gone. It would be like trying to defend the use of PHP for applications with no HTML.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  58. You say "Indicthreads.com and Javalobby.com have both concluded", but the quote you cite from our newsletter clearly states "we're close to deciding." I know you realize there's a big difference.

    We're engaging our community to discuss the possible Java options, and hopefully to learn about options and perspectives we may have overlooked. So far the feedback we have received has helped us a lot, and we're taking a much closer look at Magnolia. We have tremendous respect for what the Drupal community has going, but we also have a preference to Java solutions if all other things are equal. As is so often the case, however, you can't really compare the options in an "apples to apples" way to see if all other things are equal.

    I'm not sure yet how it will work out at Javalobby.ORG (not .com), but the good news is that whether one selects Java, PHP, python or something else - there are a lot of really great options out there.

    Rick
  59. FYI

    At BeJUG we also looked at various CMS solutions in both PHP and Javaland.

    I must say that the PHP world has some very attractive open-source solutions (we did not evalute Druple at that time, which is Belgian by the way :-) but being a JUG we selected the not-so-expensive Java Spring-based wiki solution called Confluence. This product has some minimal CMS features which is (was?) more than enough for our JUG to get started.

    However I must say that features like polls, surveys, user registration adjustments etc. need to be either imported as plugins or need to be developed extra which we would get "for free" with other PHP solutions.

    Stephan
  60. Hani's company has a new portal product: http://formicary.net/

    I've heard very good feedback on Plumtree. It's been around a long time and has a lot of modules and features.

    I've never seen Rickard's company's product, and I'm not sure if they're expanding outside of Sweden yet, but here's the site: http://www.senselogic.se/

    If you're looking for open source: http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java/view

    LifeRay is purported to be pretty good for being an open source portal, and it's not (L)GPL: http://www.liferay.com/

    BEA WebLogic and IBM WebSphere portals are both pretty big and both very successful products in this space. I've never used the IBM one. While 90% of the deployments may end up using open source portals to save money, 90% of the business dollars will be in the Plumtree / WebLogic Portal / WebSphere Portal (etc.) group. From what I've seen, there's a lot more demand for people who know these products compared to the other portals, which indicates what business are actually using.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Cluster your POJOs!
  61. Hehe, JSR is not going to make me pay more than 10 times that what I pay for my LAMP (linux-apache-mysql-php) hosting? People who are using J2EE container for their site usually have huge traffic, big funding and a very custom requirement. They can afford hiring people like us and get things build especially for them.

    On the other hand, people have limited budgets (few bucks a month) for personal and hobby site hosting. Enthusiasts normally develop some generalized kind of softwares which can be useful to more people. PHP will rock specially among small and low-traffic sites.

    These two technologies target totally different customers-base and so the codes available.

    I liked http://xoops.org more than drupal, check Smarty too http://smarty.php.net :-)

    Cheers,
    Sudhaker Raj
  62. There is a truth in the heart of using tools and that is the more complex our tool becomes, the less we will have the flexibility to change the default requirement.

    So it all is a matter of changing requirements, around java, there is excellent tools and technologies (JMS,JAXB,JTS, ....) which help us in many aspects but whenever you want to perform new tasks for new requirements, these same tools might turn into a burden and slow the development, this could be one reason for the agility in PHP products.

    The same reason we still code in C and some times Assembly.

    With all the technological advancements in industrial tools, why do you still see the simple carpenter with a wood-saw??
  63. Cost[ Go to top ]

    Hehe, JSR is not going to make me pay more than 10 times that what I pay for my LAMP (linux-apache-mysql-php) hosting? People who are using J2EE container for their site usually have huge traffic, big funding and a very custom requirement.
    Our product is JSR168 based and runs in a J2EE container.

    Our smallest customer (one man company selling fishing gear) uses a hosting solution for which he pays $50/month. All he has to care about is managing his content.

    At the other end of the scale we have government users with double DMZ's and 6 servers (Suse Linux running on Dell boxes) with integration to backend applications and custom SSO integration with their personal id card system. An upcoming customer we are in the process of deploying have 40000+ users (only counting the intranet, not the public website) with loads of servers and a couple of hundred content providers and webmasters.

    These people pay more, although nowhere near what it would have cost to use something like WebSphere (which we actually competed against in this case) and BEA Portal. They are, however, at the same time looking at massive savings due to increased usability and decreased training costs. Overall, if I understood the math correctly, they will have gotten a new and better system and yet will have "saved money" (i.e. not spent) compared to keeping the old one. That's TCO for ya!

    I suppose that's another way to look at "scalability" :-)
  64. I am a java developer for long time. But I like python or php solutins. As guys mentioned in this forum, Java world is talkign in their own fancy languages like enterprise, JTA, JMX , etc. But whatever done with those fancy words can be done in PHP or python without breaking our heads and wasting money.

    I am surprised how guys from PHP stand missed a wonderful portal server called MDprod (www.maxdev.com). I have been doing CMS research on all the languages and found this one good. It is based on PostNuke but fully re-written and have good modules and components. I don't find any buggy part in this server and its highly scalable. Its doing things more than a commercial portal systems can do. I also tried Mambo. But the problem is less user friendly Admin interface.

    MDPro has nice Authentication and permissioning system. You can untar it and ready to go. Their documentation is really good. Eventhough i know only Java in my life, I choose MDpro for many websites, because of maintenance and cost. YOu don't need to spend your time and money when you want to build a portal.

    My Final Comment: Java Sucks interms of portal servers.
  65. I've got some experience in both PHP and Java CMS worlds.

    To start with. What a customer generally wants is a customized CMS solution based on something free or inexpensive. (Why? Because if the customer got a decent budget, he'll go and buy something commercial.)
    Customers are rarely happy with something just out of the box, be it OpenCMS or PHPNuke.

    So the biggest challenge is the 'customization' of a free CMS.

    PHP solutions are indeed crazy rich in features, as long as you don't want to change them. When you need to change something somewhere, you'd have to dive into that shit code where markup is peppered with logics and SQL.

    Surprisingly, Java solutions were not any better here. What all them are basically offering you after installation is complete is some sort of interface where you have to click mouse ten thousand times to get something done. That mouse-click-in-browser programming style is definitively not something I feel comfortable with.

    I don't know if that's an attempt to appeal to non-coding types, but me, as a developer, needs clear architecture, APIs to talk to and components to extend. Also an ability plugging-in my own templates, multi-level caching and alike is very useful.

    Some time ago I've encountered that JSR-170 thing and I must say it's what I've been waiting for all these years. Based on Apache JackRabbit I've managed to implement quite decent CMS for my own pet project in about 70 hours of total efforts (I've used servlets and Velocity for frontend, Tapestry for backend and Ehcache for caching pages and their components).

    The site the CMS was created for is a sort of library, when content often has to be classified into more than one group, where alternative classification hierarchies are required, where lot of links could be there from one article to the other articles. Before, I tried to use both Java and PHP free CMS to solve that in acceptable way, but I failed miserably. But JSR-170 turned to be incredibly convenient when dealing with that sort of information structure.
  66. Oh, yes, something else I forgot.

    These PHP CMS'es in general are just one big security hole.
    They e.g. often need to write files into their own directory, which opens up wonderful possibilities to save attacker's own code onto your disk and then happily execute it with the rights of http server.
    What makes this even worse is that zillions of CMS components written by zealous but inexperienced developers, which tend to ignore all these nice security countermeasures introduced in PHP.
    And the messy nature of PHP code makes it impossible to do any security audits.
    While one definitely could write insecure Java code (e.g. inserting unfiltered HTTP request parameters directly to SQL code), Java Web applications are, by design, far more secure. Well, at least they couldn't write files into their own WARs :)
  67. Liferay is a very good Java portal. And it is Open source

    Dmitry
    http://www.servletsuite.com
  68. The PHP Advantage...[ Go to top ]

    ... modules, aka. portlets in our world. As others have stated here, there are relatively few OS portlets floating about on the internet for people to port from one portal to the other. Even some of the portal vendors have the annoying habit of hacking their portlets in to their own framework so they aren't portable at all.

    So what you don't get right now with OS Java Portals is a large bucket of components to plug in. But wait, Novell has partnered with us and is bringing 70+ portlets they are LGPL-ing (is that a word? it is now.) Aside from pluggable/portable components, I have yet to see tried and true PHP CMS that have: QA and support behind them, aren't a security nightmare, can be modified without having to look at 3000+ lines of code thrown in without rhyme or reason, have real companies standing behind the products, have seasoned developers coding the product, and adhere to universally accepted standards and specifications.

    Add to that specifications like JSR-168 + JSR-170, and I don't see why anyone would choose to go the PHP route. If you're hacking together a "Mom and Pop" CMS and want to plug in "our weekend in the bahamas PHP-gallery", go the PHP route. If you want something for the enterprise market, clusterable, scalable, flexible, will work with just about any content store, DB agnostice, and lots of other good stuff, run with the big boys in the Java OS Portal market. Shamless plug: http://www.jboss.org/products/jbossportal

    Perhaps Indicthreads.com looked at our portal when we were still in Alpha. I can guarantee you that a lot has changed since then, with the addition of several core features (http://www.jboss.org/wiki/Wiki.jsp?page=JBossPortalFeatures) and a merging of resources from Novell (http://jboss.org/jbossBlog/blog/rrusso/?permalink=C7BEC1F24F0AFE00DF2C163FB9797940.txt). You guys may want to have a closer look or even contact us next time. ;-)
  69. The PHP Advantage...[ Go to top ]

    Additional Portlets

    Could you please explain what did Novell bring exactly?
    Is there any reference?

    Dmitry
    http://www.servletsuite.com
  70. The PHP Advantage...[ Go to top ]

    My blog documents what they bring resource-wise and feature-wise for this upcoming release of JBoss Portal. You can find it here: http://jboss.org/jbossBlog/blog/rrusso/?permalink=C7BEC1F24F0AFE00DF2C163FB9797940.txt

    As for a fine-grained analysis of which portlets they're LGPL-ing, I have yet to have a firm grasp on, just lots of press releases and such from above. ;-) I would not expect them to be offered as downloadable archives until later this year... Post - JBoss Portal Final Release.
  71. The PHP Advantage...[ Go to top ]

    This CMS/Portal discussion is blurring definitions and use cases. I feel there needs to be some separation of concerns between content presentation and content production. Is it a candy or a gum, floor wax or dessert topping? I can't tell with these arguments. Most of the products/projects listed integrate the two. The bigger commercial packages clearly separate the two.

    I think the discussion needs to be framed around # of content producers and # of content consumers. How well does each product scale in these directions. QuickBooks is easier to use than SAP. Who needs Oracle when Excel can sort my records. Unfortunately, QuickBooks and Excel don't scale.

    I have worked with Websphere and WebLogic Portal with integrations to Interwoven and Documentum. I am keeping my eye on Jetspeed2 as a viable enterprise contender. It's not pretty now but all the infrastructure work they are doing to include framework integrations, a beefy security model, JSR-centric, and CMS integration albeit raw seems like a long term winner. Their licensing will drive a larger community than exo and liferay over time.
  72. Licensing?[ Go to top ]

    It's not pretty now but all the infrastructure work they are doing to include framework integrations, a beefy security model, JSR-centric, and CMS integration albeit raw seems like a long term winner. Their licensing will drive a larger community than exo and liferay over time.
    Liferay is under the MIT license, which makes it just as flexible in terms of "licensing" as Jetspeed2. Cheers, Brian Kim Liferay, LLC
  73. Why just Java and PHP?[ Go to top ]

    Surely if you are looing for an open source CMS you don't really care that much in which language it is implemented (other than for interests sake).

    As has been pointed out here, in the open source world there are "horribly" implemented solutions, but these solutions are sometimes functionally ok. There are also "nicely" implemented solutions that lack basic functionality (Web stats programs seem to exist well in this space)

    This is of course true in all closed source solutions, but you just never get to see the implementation! - so there's nothing to worry about.

    I'm surprised that nobody mentioed Plone here, its an Open Source CMS, and its getting a lot of positive press. As far as I understand its written by some pretty capable people, and certainly if its done in a pythonic way, it will have had much care and attention in its construction.
  74. I just wanted to add my experience on my CMS research. Recently I ended up looking for CMS solutions to implement some small websites. I looked into java based solutions(opencms,jboss nukes) and php based solutions(phpNuke) and also dotnetnuke. But at the end of the day when I looked at the hosting environment I had the web hosting providers mostly supported php,asp.net. Any java based hosting providers were 2 to 3 times costlier($40 per month compared to $10 for per month) and hard to find. I think unless java based hosting becomes cheaper and easily available the web hosting community will not have any incentive to adopt java based solutions.
  75. The feeling in this thread is that if you care about $40 a month for hosting then you don't need a real CMS because you're not a real business. People should remember the Fortune 5000 is composed of just about 5000 businesses. In the United States alone There are over 5.5 million small businesses with employees. It's a long way from GE, Microsoft, and Walmart to A1-Plumbing but there's a huge commercial middle ground and it's several orders of magnitude larger than the "enterprise" market.
  76. But how can you decide what a customer needs based on his budget? Most of the web hosting customers now want the end users themselves to manage and update the content to some extent, instead of having to update the web content exclusively through web designers and web programmers.
  77. No. And the reason is...[ Go to top ]

    Java loathed pages and PHP embraced them.

    There is an impedance mismatch between web apps as envisioned by Java and actual content management issues it takes to revise pages and deploy them, and have them reflected in apps that are locked in WAR files and in other source control that is different than the enterprise content management system. Designers won't look at apps and apps developers won't look at designer output.

    PHP loves pages and integrates right in. PHP page technology puts JSP to shame. It's right there in Apache, it's fast.

    Business will leave Java but it won't go PHP, no, business is going somewhere else just as bad as Java in terms of the mismatch.
  78. Hello all,

    Like many others, I was looking for a Java news publishing software that can create e-newspaper sites such as www.cnn.com or www.bbc.co.uk . After looking at all Java opensource CMS solution, I could not find any ones that can do the job.

    On the other hand, a lot of PHP solutions that can do that (Mambo, Nuke, ...) so obviously there is a big gap on CMS between Java and PHP.

    Therefore, MyVietnam Group decided to write a new CMS target at the news publishing segment. This project is written with the Faces technology (JSF). You can view demo at :

    http://www.myvietnam.net/mvncmsdemo/cms/

    To view mvnCMS in action on real site, please visit http://www.javavietnam.org/javavn/cms/vi/index.html

    More more information or want to run demo of mvnCMS, please contact us at http://www.myvietnam.net/myvietnam/myvietnam/contact

    Thanks,

    Minh Nguyen

    mvnForum developer
    www.MyVietnam.net
  79. i agree[ Go to top ]

    i agree that PHP-Solutions in the moment are the better choice!

    In my Job i'm a java developer and wanted to setup a java based open source solution @home for something like CMS, Groupware, Portal or whatever you want to call it.

    Btw. one of my constraints was zero or less programming @home.

    1.)
    So i started with JBoss Nukes (because i like the EJB-Container). No go :-(, no features, hard to get it work. rm -rf JBoss Nukes

    2.)
    Next i tried Liferay. I was happy after it worked a bit. But then... poor documentation, hard to maintain. rm -rf Liferay

    3.)
    Exoplatform. Ahh surprise. It was easy to setup. But then... poor documentation. i didn't found the roles, groups or membershipconcept. hard to maintain. for example when you want to let a group seeing other portlets than the default behavior, you have to implement your own StrutsController, Interceptor... patch some XML-Files, deploy them in an undefiend way and hope that it works. Sorry not in my private time! rm -rf exo


    So thie roundtrip costs me several evenings over months. and after that i had nothing!

    So i decided to switch to PHP-based Solutions. Now i have an nice LAMP with phpgroupware, gallery up and running. My friends, family and me are impressed as of the out of the box features and i can spend more time with my family.

    So my conclusion is:
    Use java-solutions @work where longlasting and big software is an issue and use php-solutions @home or in shorttime and smaller projects.
  80. I'm an Oracle/Java developer by trade, but also run a non-commercial website using a PHP Wiki CMS, and purely from the perspective of somebody wanting to get the job done, PHP wins hands down over Java.

    Open-source PHP code is often messy, poorly structured, fails to separate MVC, and may not scale as well as J2EE etc. But you can change the code easily enough if you want. And many solutions make good use of OO-like features of PHP (PHP5 claims to do more of this), templating, standard libraries (PEAR) etc to provide a more structured approach. And it's easy to use.

    The trouble with Java, here as elsewhere, is the vast amount of over-engineering and competing technologies. Do you go for an implementation based on Struts, Tapestry, JSF or just JSP? Should you care? What if you want to change it? By the time you figure out which one to use, there's another 10 JSRs and more APIs than you can shake a stick at.

    Yes, Java J2EE probably provides better support for massive commercial sites. But unless you have a real business case for spending a lot of time and money on this complexity, why not go for something that's quick and easy to implement? Many websites have a relatively short life-span anyway, even in the commercial sector, and there'll be another technology along quickly enough, especially if you commit to using Java.

    In his book "J2EE Development Without EJB", Rod Johnson (Mr Spring) asks the following questions regarding the choice of technologies for J2EE, and these seem relevant here too:

    "If it's the right way to solve a problem, why is it so hard?
    If it was so hard in the first palce, won't it be hard to maintain?
    If there's such an easy way to solve the problem, why is it so bad?"

    Keep it simple, stupid!
  81. What about Daisy?[ Go to top ]

    Although I haven't used it I've heard good things about Daisy. Anyone used it?
  82. What about Jahia ? (CMS J2EE)[ Go to top ]

    We are using the Jahia CMS portal and feel very satisfied. This is not free, but not so expensive and under a collaborative license, it offers an "edit-in-place" function, that makes it very easy to use. It is based on Struts, webdav, uses Lucene and is very easy to install.
    More info : www.jahia.org
  83. What about iPoint[ Go to top ]

    Again iPoint is another low cost Java portal which runs on Tomcat, MySQL and provides CMS and active portlets. It's not free but not expensive either.

    http://www.c2b2.co.uk/iPoint/ipoint?SelectedPage=19

    We built for customers who can't afford the big portal products we usually provide consultancy for.
  84. I've heard so many times things like "java is an enterprise based solution with strong standards and blah blah blah. PHP is not"
    First, as a programmer, a CMS must be easilly modified to extend functionality. PHP does not make this easy. Lots of *.php files with cross references, HTML and SQL in the same code... (talking about mambo, joomla, phpgroupware)

    Java instead.. well.. "separates logic from presentation" bulls..t. It's a pain in the .ss to modify one (talking about JBoss Portal and JetSpeed).

    As a client: nothing of the above matters to me. I need a rich CMS portal, with all features indeed working. Does matter the "separation between logic and presentation? NO. Does matter if the code is unreadable? NO. Do i care for high standars? NO. It works? YES. Well that would be my decision.

    As a Java and PHP developer, i'll choose PHP portals. With no doubt.
  85. I would say that the PHP community are well ahead on the open source front, but there are some interesting java offerings too.
    Manifest CMS for example gets away from your traditional browser based interface and instead uses MSWord and custom client applications to acheive its goals. communication is still via http(s) though. Its mostly drag and drop, and is a very effective portal with lots of scope for building plugins.
    Check it out if you are open to the idea of a different way to manage your site and your content.
  86. Haven't you seen Liferay ?[ Go to top ]

    I was eveluating CMS portals for our church and finally adopted Liferay. check it out at www.liferay.com
  87. Look at the AtLeap too.[ Go to top ]

    http://atleap.dev.java.net is a multilingual free Java CMS with full-text search engine. Moreover AtLeap is a framework which allows you to rapidly start your own Web application.
  88. I searched a lot for a java based cms tht can match drupal, but no luck. jYog.com
  89. LAMP and JEE, why the fight?[ Go to top ]

    guys, i have been reading this thread, and i dont see why there is a fight between lamp and jee, one is a car and the other is a tank, the tank is not supposed to be driven on the street, however it is very much possible and same is the case for a car which is not supposed to be driven in a battle field but nobody will stop someone from doing it. i have around 10 years of experience in java but i like to evaluate the right technology for the projects i do. and i dont believe anyone would disagree on this forum that jee is the right choice for enterprise applications (the second "e" in the jee is supposed to be for that) and for websites and smaller scale web applications where transactions and other jee platform is not a required lamp is a good platform.
  90. I cant agree more[ Go to top ]

    I agree to every word of yours. Everything in this world has a value.
  91. Melenti.org Java Joomla[ Go to top ]

    Hello to everyone, yes the need of a simple JAVA JEE CMS to deploy and use is there and we are changing this. Please check www.melenti.org and our projcet in source forge we are crating a Joomla in JAVA based on GWT, JPA, Spring. We have already released code in the SVN and we would like you to give it a try so we can show PHP world , easy to use its not just them,JAVA its more powerfull I think on enterprise aspects. Please send us your comments