It was always helpful in 10g to be able to manually enable
or disable a component by using the components.hda file, but things have
changed in 11g which makes it much more helpful.
The component wizard can always be used to do this, but
sometimes the easiest way is to hit the configurations directly. NOTE: this is
only a trick for people that know the implications of these changes. Randomly
changing hda files will have negative consequences!
One of the key changes is that the WCContent Admin Server
& Content Server both run within the same managed server. In 10g, there
were two separate jvms that were controlled separately. Meaning, the content server might not have started
correctly, but the admin server never was down. That means that the component
control was never out of reach.
But, as of 11g, the Admin Server & Content Server both
run together within the same Managed Server. That is, they are closely coupled
and therefore more reliant on the stability of each other.
If a sketchy component is installed and botches the startup,
you might not have the ease of access to flip off the component in order to
restart the Managed Server.
Here's where and how that's done in 11g:
Find the following file:
<domain>/ucm/cs/data/components/idccs_components.hda
Note the definition is as follows:
16
name
location
status
classpath
libpath
installID
featureExtensions
classpathorder
libpathorder
Launchers
LaunchersOrder
componentsToDisable
componentTags
componentType
useType
version
The "status" is what we're after. It's values are
"Enabled" and "Disabled"
example of a disabled component:
BrowserUrlPath
components/BrowserUrlPath/BrowserUrlPath.hda
Disabled
$COMPONENT_DIR/classes.jar
1
idc,integration,system,home
home
2010_03_19 (build
16)
You can see that a number of values are empty, which is
fine. Make sure you don't alter any other values!
After disabling your custom component, you will be able to
re-start your content server without any related complications!
Hope this helps out!
-ryan
