Skip to main content

class loading while booting

1 reply [Last post]
Joined: 2010-08-10

Hello everyone,

Thanks to you, I am getting to learn more about OCAP RI.

What I want to know at this time is about class loading while booting.

There might be many classes loaded while booting - it means before applications(Xlets) start. For example, I think "SIDatabasesImpl" class should be initialized before any applications start.

So, how can I know which classes are loaded and initialized while booting (before Xlets start)?
Is there any configuration file(s) to startup those classes?

Jinwoo Lim

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-07-03

The main functional areas of the stack are controlled by the "Managers". A Manager is a Java interface which provides functionality for a specific subset of OCAP/MHP. The Manager interfaces are located in the org.cablelabs.impl.manager package.

There is also a higher level controller for all the Managers called ManagerManager. This class reads a properties file to determine which class should be used to implement the Manager's interface. This mechanism allows us to replace functionality for testing purposes without having to rebuild the stack. For example, we have a Manager that controls class file authentication. We have two implementations of that Manager -- one that performs authentication according to the OCAP/MHP specs; and one that does no authentication for testing purposes.

The properties files that contains the Manager configurations are located in each extension's java source directory ($OCAPROOT/java/src/base/, $OCAPROOT/java/src/dvr/ You will see that these properties files contain the definition of each Manager's implementation class. You can override any of these settings by placing your own definition in the $OCAPROOT/bin/$OCAPTC/env/ file.

Finally, you will see in the properties files a list of "autostart" Managers. These SHOULD NOT be modified. The stack actually tries to minimize the Managers that we put in this list. The best way to make sure a Manager is initialized is to reference that Manager's singleton instance in code that needs it -- like this:

AuthManager auth = (AuthManager)ManagerManager.getInstance(AuthManager.class);

The Managers are responsible for the startup of much of the stack. Any classloading that takes place before an Xlet is started is a direct result of a reference by a Manager during startup.