WebSphere® Portal delivers a single point of access for applications and information within a customizable and extendable framework. It integrates an application deployment platform with team collaboration, content publishing, workflow, and enterprise application access services. For more information, see the developerWorks WebSphere Portal page.
Question: I installed WebSphere Studio 5.0 and updated it to 5.0.1. I downloaded the Portal Toolkit 5.0 and it will not allow me to install the Portal because I am missing 4 fixes on the WebSphere Application Server runtime (which it lists and they are also recorded in the documentation as required). My question is where can I find those fixes - I've looked everywhere and can only find one (PQ76567). The docs only refer to the CD. I also found PQ73644, but only as part of a fixpack and when I installed the fixpack, the Portal installer still did not recognize that it was installed.
Answer: These fixes are part of the WebSphere Portal V5 shipment and are not made available exclusively for Portal Toolkit V5 because it is assumed that users of the Portal Toolkit V5 also have access to WebSphere Portal V5. If this is not the case, contact IBM Service and request that these fixes be sent to you.
Question: I have two questions: 1) I need to do password aging, but do not need a high end solution like TAM. Is there a way to do this with LDAP or within the Portal? 2) I need to deploy MapPoint in a portlet - is this difficult?
Answer: 1) WebSphere Portal itself does not support the concept of password aging, and neither do LDAP servers as far as I know. 2) MapPoint is a Web Service. It should be simple enough to build a portal that renders the XML feed from the Web Service as portlet content. There are portlets available on the Portal Catalog that help you build a Web services-based portlet, but I am not familiar with any of them.
Question: I just recently installed WebSphere Portal 5.0. While experimenting with changing themes, I switched from the Admin theme to the Admin with the Left Navigation theme. In the new theme, I no longer have access to an Adminstration link, and thus cannot change it back or administer my portal. Any ideas? (submitted by email@example.com)
Answer: After you install V5.0, the default administration theme is "Admin with Left Navigation", so I presume based on your description, that you had at some point changed to the "Admin" theme before now, trying to set it back. I also presume that once you exit Administration by clicking on the MyPortal link, you no longer see the Administration link. The visibility of that link should not depend on what theme you chose for Administration, but instead, depends on your authorization to enter administration. Did you make any changes to your user's authorization within the portal, such that the user no longer has rights for administering the portal?
If you still suspect that it has something to do with the theme choice you made for Administration, you can reset your choice using XMLAccess. Refer to the WebSphere Portal V5 InfoCenter on how to use XMLAccess to administer portal. Basically, you can export the portal's configuration, then locate the <content-node> element for the Administration node, and change the
themeref attribute to point back to the Admin theme's
I have a problem with my J2EE project that has a Portlet project in it. I can deploy it at the Portal server, but when I try to invoke the portlet, a problem occurs. In the portlet, there are references to objects from the EJB project, part of the whole J2EE project
EGovernmentEJB.jar). In the portlet's project
manifest.mf file, there is
Class-Path: EGovernmentEJB.jar, where the objects that the portlet is referencing are located.
EGovernmentEJB.jar is also put in the
WEB-INF/lib/ directory of the Portlet project.
So when everything is deployed and I invoke the portlet (that has references to EGovernmentEJB, the EJB part), the output in the log is:
SRVE0020E: [Servlet Error]-[egovernmentportlet.EGovernmentPortlet]: Failed to load servlet: java.lang.Error: Unresolved compilation problems: The import bg.telelink.egovernment.forms.form51.dto cannot be resolved The import bg.telelink.egovernment.forms.form51.util cannot be resolved Form51ServiceConstants cannot be resolved Form51LabelsDTO cannot be resolved (or is not a valid type) for the field EGovernmentPortlet.form51LabelsDTO Form51ServiceConstants cannot be resolved The method createForm51() is undefined for the type bg.telelink.egovernment.forms.form51.ejb.Form51SessionFacadeLocal form51LabelsDTO cannot be resolved The method retreiveForm51EntireSkeleton(java.lang.Short) in the type bg.telelink.egovernment.forms.form51.ejb.Form51SessionFacadeLocal is not applicable for the arguments (short) form51LabelsDTO cannot be resolved Form51CustomDTO cannot be resolved or is not a type The method getFilledDTO(org.apache.jetspeed.portlet.PortletRequest) is undefined for the type egovernmentportlet.EGovernmentPortlet Form51DTO cannot be resolved or is not a type fo -- --
"All cannot be resolved"" refs are from
(submitted by Dobri)
This seems like a classloader visibility issue. According to the Servlet 2.3 Spec, I do not see what the defined behavior should be of specifying the Class-Path header in the WAR's
manifest.mf file. Unfortunately, I have more questions than answers. Are there other instances of
EGovernmentEJB.jar? Since other JARs contained in
WEB-INF/lib are automatically picked up, have you tried removing the Class-Path header from the portlet WAR's
manifest.mf? Could it be that there are problems with the EJB loading? Does the EJB itself have access to
EGovernmentEJB.jar? EJBs are loaded at the application server classloader level, so the EJB could not see any resources under the portlet's
WEB-INF/lib directory unless you had a copy of
EGovernmentEJB.jar under something like
/AppServer/lib, in which case you might have resolution conflicts. If you have a real EJB that requires access to these same resources, consider putting under
AppServer/lib, instead of within the portlet. The portlet should see these resources there.
Question: I would like to inquire on the integration between the Lotus products and WebSphere Portal. WebSphere Portal V5 only has Domino R5.0.12 support currently for Sametime, Quickplace integration. However, Domino is already up to R6.5 and many customers use R6.x or above. What is the recommended path for Domino R6 users to implement Lotus collaborative components to the Portal?
Answer: Sametime 3.1 is being certified with an upcoming fixpack of WebSphere Portal V5 (called 5.0.2). With Sametime 3.1, you can use Domino 6.x for your LDAP. There is a future version of QuickPlace that is designed to work with Domino 6.x. The product plans are not finalized so I cannot release any details on that, but presumably WebSphere Portal will pick up support for that level of QuickPlace when it is available.
Question: We are having Portal in Suse Linux with user authentication from MS ADS. Currently, users are added to OU in ADS and also in the Users table in DB2 local in Linux. We want to add the user to the Portal group during the self-registration by writing the customization code. This is for the ACL in the Portal so that the users are automatically added to group after self-registration. We have set the ACL in the Portal based on this group already existing. We want to achieve is by adding a row into Member table in DB2. We are not able to find any code or samples for this. Is there a right way or any other way to achieve this?
Answer: WebSphere Portal provides the PUMA API for managing users and groups. It is not really a publically supported API, so we provide documentation for it with the understanding that the interface may change over time. In fact, in WebSphere Portal V5, the interface is deprecated. We intend to replace it with a publically supported WebSphere Member Manager (WMM) interface in the near future, but the PUMA interface will remain until the WMM interface is available.
Using the PUMA interface, you can programmatically manipulate group ownership, and thus at the time of registration, assign the new user to a specific group. For more information on this interface, see the WebSphere Portal Support site. You will need a Passport Advantage user ID and password to access this document.
Question: I have WebSphere Portal V5 with Collaboration Center installed, Sametime server 3.0, and Quickplace server 3.0.1 behind the company's firewall. Now I want the Portal to be accessed from the Internet. What are the TCP ports that have to be opened in order for all the servers to work together?
Answer: QuickPlace uses the standard HTTP port for communication (80). Sametime uses a private port (1533).
Question: I had a problem starting WebSphere Portal server. The error is "Failed to load servlet." I installed WebSphere Application Server and WebSphere Portal a few days ago. It ran fine. I was able to start Portal and browse it. Now it gives this error, and I didn't do anything with it since the installation. (submitted by Yifei)
I suggest inspecting the
SystemErr.log files under the
.../PortalServer/log directory to see if you can find the errors. Hopefully, the error messages earlier in the log will yield the reason for the failure. If not, or if you can't figure out a way to correct it, then I would suggest contacting IBM Service.
Question: When will the ability to do multi-developer Portlet Remote debugging be available? We would like to share instances with many developers for remote debugging on higher powered systems (AIX). (submitted by Matt Langley)
Answer: Remote debugging is available within the Portal Toolkit. There is nothing to prevent each of your Portal Toolkit installations to use a common remote Portal Server for the debugging environment.
Question: We would like to design a portlet to call a separate Java servlet/JSP that will pop up in another browser window. How would you recommend doing this? Should it be in the same WebSphere_Portal server or "server1" on the application server? How can we pass the data, such as user info, from the portlet to the Java servlet? How can we maintain the servlet called under the portlet security framework?
Answer: The most common solution for this is to package a servlet with your portlet within the same WAR. We have several portlets that do this. In your portlet's JSP, you can have an HREF with a target="_blank" attribute to create a new window for the other servlet. The servlet is registered in the portlet's web.xml file and is assigned a context root to access the portlet.
Because the servlet and the portlet are in the same Web module (WAR), they can share session information.You can have your portlet put application-specific data in the portlet session that the servlet can then pull out. The trick is, though, that the data put into the session will be namespace-encoded by the portlet's WAR name, so you will need to figure out what that pattern is for that Web module and use it to pull attributes off the session (or simply look at all of the attributes in the session and use the right one).
I'm not sure exactly what you mean by the portlet's security framework. You cannot grant authorization to the servlet, only the portlet, through the portal. You must use the portal to access the portlet, so if the portlet is unavailable, then the associated servlet is unavailable. If the portlet is required to set certain context information in the session for the servlet, then directly addressing the servlet (around the portal) can cause an error because that context information is missing.
Question: Currently WebSphere Portal V5 Express requires additional setup for a database and LDAP server. Do you recommend implementing on the Cloudscape database first, and then migrating to a database such as DB2 when required, or going straight to DB2? Will any data be lost from the migration from Cloudscape to DB2 such as from the Portal Document database?
Answer: The database transfer is designed to preserve all data from Cloudscape to whatever your target database happens to be. That being said, though, the complexity and chance for error increases with the complexity of the data being transferred. If you know you are planning to move to another database, I would plan to do that sooner than later.
Question: I have installed WebSphere Application Serverwith IBM HTTP Server 126.96.36.199 with ssl configured. What is required to upgrade to IBM HTTP Server 188.8.131.52 without disturbing the current installation. How I will do that?
This is a WebSphere Application Server question, not so much a Portal question, but you should be able to upgrade safely. Backup your
httpd.conf file as it contains (in the last few lines) the configuration entries that register the WebSphere Application Server plugin to the Web server. If, after the upgrade, these lines are gone, you can simply add them back from the backup.
- Guide to WebSphere Portal 5.0
- Applying the State Pattern to WebSphere Portal V5 Portlets: Part 1. Overview
- Comparing the JSR 168 Java Portlet Specification with the IBM Portlet API
- Using Cooperative Portlets in WebSphere Portal V5
- Extending the State Pattern for Multi-Portlet Applications
About Meet the Experts
Meet the Experts is a monthly feature on WSDD. We give you access to the best minds in IBM WebSphere, product experts and executives who are waiting to answer your questions. You submit the questions, and we post the answers to the most popular questions.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.