Extending default portal v8 install template to support change context root as part of rafw build
Spent a lot of time building portal v8 recently, all of which don't have the defult context root.
So initially I'd build it, then i'd run the change context root task (or rather a custom version that runs multiple actions), to get result i want.
I've just noticed that portal v8 actually supports changing context root as part of installation, using the installation manager, and aftera bit of digging I note that it uses these properties in the response file
data key='user.wp.custom.personalhome,com.ibm.websphere.PORTAL.SERVER.v80' value='myportal'
data key='user.wp.custom.defaulthome,com.ibm.websphere.PORTAL.SERVER.v80' value='portal'
data key='user.wp.custom.contextroot,com.ibm.websphere.PORTAL.SERVER.v80' value='Connect'
data key='user.wp.uri.values.changed,com.ibm.websphere.PORTAL.SERVER.v80' value='true'
note I've dropped off begin and end angle brrackets for each line.
In this case i changed the context root to Connect from wps.. note you need to set the user.wp.uri.values.changed,com.ibm.websphere.PORTAL.SERVER.v80 to true.
To achieve that result i added a custom insrtall template with these new values
data key='user.wp.custom.personalhome,com.ibm.websphere.PORTAL.SERVER.v80' value='@WP_PERSONALIZED_HOME@'
data key='user.wp.custom.defaulthome,com.ibm.websphere.PORTAL.SERVER.v80' value='@WP_DEFAULT_HOME@'/>
data key='user.wp.custom.contextroot,com.ibm.websphere.PORTAL.SERVER.v80' value='@WP_CONTEXT_ROOT@'/>
data key='user.wp.uri.values.changed,com.ibm.websphere.PORTAL.SERVER.v80' value='true'
note lines are wrapped here for formatting issues.
In my case, every portal build has a changed context root, so I don't wiorry about hardcoding the uri changed key as true, If I had a mixture I'd add a new action based on create_wp_install_response_file_for_im, that had an aditional substitution after a test for a change in these values from the default.
You may ask why bother to do this, when we have the tasks to do this already, my answer is that if we can get the product (portal) to do this natively as part of the build, then we should. It keeps us closer to the vannilla build path, and hence less likely to hit defects.
Of course others may disagree :-)
And why put this here, it seems like the best place to write it where other rafw users will find it..
If there's a better place let me know and I'll post a link there
So initially I'd build it, then i'd run the change context root task (or rather a custom version that runs multiple actions), to get result i want.
I've just noticed that portal v8 actually supports changing context root as part of installation, using the installation manager, and aftera bit of digging I note that it uses these properties in the response file
data key='user.wp.custom.personalhome,com.ibm.websphere.PORTAL.SERVER.v80' value='myportal'
data key='user.wp.custom.defaulthome,com.ibm.websphere.PORTAL.SERVER.v80' value='portal'
data key='user.wp.custom.contextroot,com.ibm.websphere.PORTAL.SERVER.v80' value='Connect'
data key='user.wp.uri.values.changed,com.ibm.websphere.PORTAL.SERVER.v80' value='true'
note I've dropped off begin and end angle brrackets for each line.
In this case i changed the context root to Connect from wps.. note you need to set the user.wp.uri.values.changed,com.ibm.websphere.PORTAL.SERVER.v80 to true.
To achieve that result i added a custom insrtall template with these new values
data key='user.wp.custom.personalhome,com.ibm.websphere.PORTAL.SERVER.v80' value='@WP_PERSONALIZED_HOME@'
data key='user.wp.custom.defaulthome,com.ibm.websphere.PORTAL.SERVER.v80' value='@WP_DEFAULT_HOME@'/>
data key='user.wp.custom.contextroot,com.ibm.websphere.PORTAL.SERVER.v80' value='@WP_CONTEXT_ROOT@'/>
data key='user.wp.uri.values.changed,com.ibm.websphere.PORTAL.SERVER.v80' value='true'
note lines are wrapped here for formatting issues.
In my case, every portal build has a changed context root, so I don't wiorry about hardcoding the uri changed key as true, If I had a mixture I'd add a new action based on create_wp_install_response_file_for_im, that had an aditional substitution after a test for a change in these values from the default.
You may ask why bother to do this, when we have the tasks to do this already, my answer is that if we can get the product (portal) to do this natively as part of the build, then we should. It keeps us closer to the vannilla build path, and hence less likely to hit defects.
Of course others may disagree :-)
And why put this here, it seems like the best place to write it where other rafw users will find it..
If there's a better place let me know and I'll post a link there