I'm looking at a solution to manage my content between a website & intranet and was playing with Hippo CMS in combination with Jetspeed. It looks good, bus does anybody have any experience with this combination? And where do you shop for more portlets?
I have some experience with this solution. Hippo introduced a completely rewritten version of their CMS beginning this year. This new version 7 eventually will get all features available in the previous version, but currently that is not the case (yet). However, the rewrite also made the CMS much more flexible and extensible.
They provide a toolkit for developing websites using the Hippo CMS as backend. This toolkit (called HST2) produces fairly generic components, since they can easily be converted to portlets which can be deployed on a Jetspeed portal (in fact, you only have to change one build parameter to get this working). Hippo also has an integrated solution in their product line-up called Hippo Portal. However, this is based on an old version of Hippo CMS and Jetspeed and will eventually be deprecated (I suppose).
Jetspeed is a nice portal. Recently version 2.2.0 was released. This version implements the Portal 2.0 spec, and as such can run all portlets which are conforming to this spec. There is no one location where you can get Jetspeed-specific portlets, but searching on the internet will probably give you some results (as said, Portlets doesn't have to be Jetspeed specific, if they implement the Portlet 2.0 spec (JSR-286) they will run on Jetspeed).
It is also pretty easy to create your own portlets. We use Spring Portlet MVC for this task, making the development of a portlet almost as easy as developing a generic Spring MVC app.
Related
I'm looking for a java based CMS application that will allow me embed specific UI 'component's or 'regions' (eg. newsfeed, page-section, video, etc.) into pages of an existing J2ee web application. The idea is to mix managed content with custom web-application function, where the 'dominant' web-application is our custom application but it integrates these components for which the content can be manged by A CMS. I have looked through a number of CMSs (Jahia, Magnolia, Alfresco, Nuxeo, Walrus and a couple more), but haven't found anything that readily provides managed components that I can integrate easily. Integration can be at the controller, jsp or even client (Ajax/iframe) level, but I am trying to stay away from introducing portlets into my stack.
I am currently using Spring and Struts2.
Thanks
I believe the Portlet Framework suits your needs here. Many CMS's support this specification and the main point is to absolve you from doing the low level, often very messy integration you're talking about. I use Liferay 6 with moderate satisfaction.
At work we have both a legacy web app (a decade or so) as well as a new web application (< 6 months), both developed in Java. At the moment, both are running on different versions of JBoss AS (legacy app is currently using Spring 2, if I'm not mistaken, newer app built on Seam 2).
We're looking to create a section where users can view relevant information from both sources in the form of portlets (as well as potentially other compatible portlets).
I've never used portlets before and was wondering what technologies I should be looking at and how I should approach this task?
Is it possible to integrate the host portlet section in the first application or would we need a new deployment?
I've just gone through a portal selection process where I work and we've found several ways to approach this-
You can purchase a high-end portal product such as WebSphere Portal Server or Oracle's portal product (whatever it's called this week), you can go Liferay community or Enterprise (the enterprise version comes with support and gets new features earlier than community), or you can go purely opensource with Apache Pluto. All of those will give you real, JSR compliant, portlet containers. If you decide to go that route (as apposed to using apache tiles to aggregate at the glass and avoid the hassle of a portal or going to a non-portal technology such as Adobe Flex & Mosaic) you then get to choose how you access the legacy applications:
Using the portlet-servlet bridge, if your portal server has one;
Try and link the truly legacy applications with an IFrame portlet.
Re-implement the user interface functionality (you were using the MVC(s) pattern, right?) as portlets.
I'd guess that the older application that you mentioned is probably not designed for the UI to be replaced and you'd be best served using options 1 or 2, but I can't say for sure without seeing the app itself.
I think you may also want to look at using a portal bridge implementation.
Check out:
http://portals.apache.org/bridges/
http://myfaces.apache.org/portlet-bridge/index.html (for JSF)
I recently came across spring surf project and Spring webscripts .
Both these technologies (I guess) seem to come from Alfresco developers
Web Scripts
Surf
Is it correct ?
As I was investigating both of them couple of hours, it seems to be very clever technology. Little bit focused on CMS, but it makes better impression and sense than JSPs, Icefaces (which I haven't liked for many years, but I've been forced to use them).
It's a shame that both technologies are in state of incubation within springsource.
Could please anybody who has experience with them tell us some stories from production use ?
I noticed that Surf can be used together with Spring Roo. Is there any other support, like maven, IDE etc ?
Yes, those technologies were developed by Alfresco and then donated to Springsource to detach them from Alfresco and become first-class web development libraries.
I'm not aware of any remarkable use of those libraries out of the Alfresco scope, but that's most likely because of my current focus being on Alfresco, or because they are still quite new as standalone projects.
Have a look at Alfresco Share or the Web QuickStart to see how web scripts and Surf are used to create fully functional and standalone applications.
Spring Surf and web scripts are built with maven and deployed into Alfresco maven repository, which should give you enough support for your maven builds. I'm not aware of any maven archetype for Surf or web scripts.
As per developer tools, I'm only aware of Spring Roo. The official documentation could bring some more information, though.
We are in the process of working on our second generation of our eCommerce site. The contracting firm that has been brought in is pushing for the use of WebSphere Portal vs using JSP/Spring MVC etc to build out the UI part.
Many parts of the new release will be based on Version 1.
The contracting firm is an IBM partner - so I assume that there is a conflict in interest in determining the best solution for the UI.
So, I am reaching out to the group to get a feel as to is using IBM WebSphere Portal worth the money - ROI?
Going forward we will be using an off shore company to maintain the application once it goes live - so we have to consider those skills sets.
We provide Web Sites to Consignors to allow them to sell/auction their inventory of Vehicles. The underlaying Business Logic is pretty much the same for each consignor and is handled in a separate tier. The issue is that currently we have created a core set of UI and Controllers which are then extended into a Consignors project. Each Consignor "Store Front" is a separate deployment.
Here is what I know or have been told about Portal:
IBM WebSphere Portal OTB will handle the basic security - user log in and the portlets that they can see (Spring Security can do the same thing)
IBM WebSphere Portal OTB can handle the theming or re-skinning the portlets based on what company the user is associated with. (Standard UI practices can achieve the same thing)
IBM WebSphere Portal can provide re-use of Portlets (Not sure I buy this since so far each customer has demanded their own screen layouts along with the data collected and how it is displayed)
IBM WebSphere Portal can help with time to market - That is start with a base reference implementation and then show them what can be changed in a 45 - 60 day turn around.
I am open to anyone who can also provide more benefits of its usage.
Follow on Question
In response to a statement made by #Bozho - what are the guidelines if any to determine if a portlet solution is warrantied.
IBM does not trigger any good references in terms of quality software in my head. And all points above are marketing nonsense. There are two things you need to assess:
do you need a portlet solution. (This is regardless of the portlet implementation).
which portlet implementation to choose
I cannot decide these for you, but I can tell you that:
spring provides even advanced user and security handling (spring-security)
even if you choose portlets, you can use spring. Spring has portlet support.
if you choose portlets, make sure you choose a good implementation. As I mentioned, I wouldn't go for IBM.
It entirely depends on what your end game is.
It looks like the supplier has recommended Websphere Portal with a view to setting up a virtual Portal for each Consigner - so they can be managed separately, which make sense as you can just deploy the same portlet in each virtual portal with a bit of customization and also the consigner and user roles can be handled easily by portal out of the box.
However Portal is a pretty big piece of kit. If you want to integrate content from various sources and present the data in a standard way to the end user based on their role,etc, or it you're planning on using some of its existing functionality, i.e. dynamically updating portlets on the same page through events, Web Content library, integration with Remote Portlets, integration with collaboration tools, integration with process server/bpm tasks, blogs, wikis, etc, then it might be worth using a portal solution.
If however all you want to do is essentially create a web app, then Portal's total overkill and I'd just stick to an app server with whatever frameworks make the job easier
It's been suggested that this might be a reasonable approach, in order to minimize changes to an existing server configurations, but is it actually valid/supported? I've not been able to find anything specific either way.
In practice, with a JBoss Portal V2.4.2 server, there appears to be some class-loading issues, so things such as the downloadable Stripes example or a standard Wicket quickstart app don't run, but I'm not sure if the problem there is a server-specific one or a generic one - Anyone?
Note: This isn't about displaying/moving an existing web-app into a portal, simply if a Portal Server should also be a valid AppServer?
JSR 286 (Portlet 2.0) spec:
PLT.2.7
Relationship with Java 2
Platform, Standard and Enterprise
Edition
The Portlet API v2.0 is based on the
Java Platform, Standard Edition 5.0
and Enterprise Edition v1.4. Portlet
containers should at least meet the
requirements, described in v 1.4 of
the J2EE Specification, for executing
in a J2EE environment.
It is therefore not unreasonable to expect standard app-server applications to work under a portal.
However, by definition, a portal is going to include more libraries in the global class space. Adding libraries to the container always introduces the risk of incompatibility and the need to manage what classes/resources are exposed to your application and how (application-first class-loading, etcetera). I've had problems in the past with third part libraries whose dependencies conflicted with a version that shipped with the portal. I wouldn't expect dependency management to get any easier.
Write once, test everywhere, as they say.
From my experience that is a valid suggestion. Portlet Apps are often also Webapps (they might contain a servlet for example to allow access to application logic also by links to be rendered in one of the portlets), so they contain both portlet.xml and web.xml and need j2ee classes and jsr168 classes. The WSRP standard also contains resource link type with is supposed to represent a normal appserver for the remote server.
Websphere portal server is also an app server.
I have mixed servlets and portlets in a single web application using JBoss Portal, BEA WebLogic Portal and Apache Jetspeed 2.
However, converting a servlet to a portlet can be difficult. Using bridging technology such as Portals Bridges do exist but I have been lucky enough to avoid having to do such a conversion and have no direct experience other than playing with the tutorials.
Hmm... but can it /exclusively/ contain servlets, or in other words, does an app need to have at least 1 portlet? (I don't have/want to serve a portlet, just a servlet, but I've only got a Portal Server!)
Even if the application contains a portlet, nothing says you need to expose that portlet on a page somewhere. If you write such an application, simply author as many servlets as you wish, link to them directly and not place any dummy/default portlet on any page anywhere.
I wrote a JSR-168 compliant app with an empty portlet and a servlet that was used to retrieve some XML stock price data. For several months all that was ever invoked was the servlet, the portlet was never visible anywhere on the site. Later I added a portlet which provided some additional data from the XML feed.
The answer is that yes, it is valid, but the specific JBoss Portal V2.4.* versions appear to have class-loader issues such that only the more basic web-apps will run correctly.
I assume that the question has to do whether a standard web application can be rendered as a portlet from a Portlet container. This is not possible. The portlets need to be based on the GenericPortlet class and have special deployment descriptors. There is the JSR-168 standard, which specifies the requirements for the portal. The JSR-286 specification is on the way.
The only thing you could do is to create a portlet that will serve your existing application through an iframe, but this is of course ugly.
There is a free book for portlets called "Portlets and Apache Portals", which could be useful. Consult also the specification. This blog spot is interesting.