Once the portlet is deployed, the DM will push these changes to all the portal servers and once the portal application is updated on all the Portal Server you can activate it. Now problem is we dont know how much time this process will take. SO irrespetive of if you deployed a portlet using either XMLAccess or "Manage Portlets" portlet, you should execute the
ConfigEngine.bat activate-portlets
task to synchronize changes to all portals and activate deployed portlet.If a portlet is deployed through WebSphere Portal, it first takes whatever configuration information it needs from the portlet’s WAR file, and then it generates a unique object ID for this portlet. WebSphere Portal then wraps the portlet’s WAR within an EAR definition, giving it a name based on the portlet’s display name, suffixed with the generated object ID. This guarantees that the portlet’s underlying enterprise application name is unique to this portal. In the event that this portal is clustered, the new enterprise application will be common to this cluster, but unique from any other cluster in the cell, because again the object ID is guaranteed to be unique.
Important Note: You can use the XMLAccess task to delete a portlet common across clusters. If the portlet was predeployed as a standard EAR, then each cluster must be first notified of the portlet removal before the EAR can be uninstalled. The administrator must use the XMLAccess application to import a
No comments:
Post a Comment