If you mean, “How do I create a custom module for Wowza Streaming Engine?”, create a Java class that extends ModuleBase, package the compiled class in a JAR, and register its fully qualified class name for the target application. The application must be restarted for a newly added module to take effect.
Here, “Java module” means a Wowza server-side extension loaded for an application. It does not ordinarily mean a Java Platform module declared with module-info.java; those are separate mechanisms with different purposes.
What a Wowza Java module is
A Wowza server-side module is Java code associated with a particular Streaming Engine application. Wowza describes these modules as loading when an application starts. They provide a place to add application-level behaviour, including work related to streaming protocols such as HLS, MPEG-DASH and RTSP/RTP. The application scope matters: registering a module for one application does not make it an extension for every application on the server.
A module normally extends Wowza’s ModuleBase class. The class can implement lifecycle methods, such as an application-start hook, and can expose custom methods for the application or other code to call. Wowza’s API reference describes ModuleBase as the base class for server-side modules and notes its support for function parameters, return data and simplified logging. That is the relevant meaning of “module” for this workflow.
The Java Platform module system solves a different problem. A named Java module can declare dependencies and specify which packages it exports or opens. That declaration is typically written in module-info.java, and the Java compiler has module-path options for this model. Those concepts may matter to a Java application that uses named modules, but Wowza’s documented custom-module path is a class, a JAR in the Engine installation’s lib directory, application registration and a restart. Do not add module-info.java just because the Wowza extension is called a module.
For the official procedure, see Wowza’s instructions for using Streaming Engine Java modules. For the separate Java terminology, Oracle’s Java Language Specification section on modules explains what a Java Platform module declaration does. Keep those two references distinct as you design and package your code.
Choose the application extension point
Start with the behaviour you need, not with a class template. A module is a reasonable fit when application-level code must react to application events, interact with streaming or client APIs, or provide a callable custom method. Wowza’s examples cover tasks such as recording, scheduling, transcoder controls, authentication integration and packetisation behaviour. An example can help you understand the extension point, but it does not establish that you need a custom module: first check whether an existing feature or utility already meets the requirement.
If your requirement is about server-wide lifecycle events rather than one application, investigate Wowza’s listener approach. If you need to handle HTTP requests, examine an HTTP provider instead. These extension points have different scopes and interaction surfaces, so choosing a module for an HTTP interface or a server-wide event can add needless work and make deployment harder to reason about. Wowza’s Java API overview outlines the available development approaches, including modules, listeners and HTTP providers.
Before writing code, record which application will load it, which event or call should trigger it, and which Engine/API release you are targeting. Also decide what external dependencies or services it needs. This simple design note gives you a practical check against the target installation: a sample signature or dependency that works with a different API release may not be right for your Engine.
For a YouTube channel owner comparing always-on delivery approaches, a custom Wowza module is development work on the streaming application, not a shortcut for keeping a local playback computer running. The operational trade-off is different from a VPS-based channel setup, as described in this guide to running a 24/7 bhajan stream on a VPS. Choose based on what behaviour needs custom code and who will maintain it after a restart or software update.
Create a ModuleBase class
A minimal class follows the shape of Wowza’s examples: it imports the required Wowza APIs, declares a public class and extends ModuleBase. The exact imports and method signatures should come from the API documentation for the release you intend to run. Treat code copied from an example as a reference, not as proof that every signature remains compatible with your installed Engine.
A lifecycle method and a custom method have distinct jobs. For instance, Wowza shows onAppStart(IApplicationInstance appInstance) as an application-start event hook. A method such as doSomething with client and request arguments illustrates a callable custom method; it is not itself an application-start event. Keep startup work in the appropriate lifecycle hook and give separately invoked behaviour an explicit method whose parameters match the use case.
A schematic outline might look like this, but it is deliberately not a complete buildable project. The imports, argument types, method visibility and available callbacks must be checked against the target API version before you compile:
public class MyModule extends ModuleBase {
public void onAppStart(IApplicationInstance appInstance) {
// Add only the application-start behaviour you need.
}
public void doSomething(IClient client, RequestFunction function,
AMFDataList params) {
// Implement a callable operation if your use case requires one.
}
}
The placeholder body is not a tested implementation, and its displayed types are not a compatibility promise. Consult the ModuleBase API reference and the API materials for the installed release. Add only methods and dependencies that support a defined requirement. A module with fewer responsibilities is easier to test and less likely to fail because of an unrelated service or library.
Plan for observable outcomes while you write the class. Decide what the application log should show when startup succeeds, how you will distinguish an expected event from a failed call, and what should happen if an external dependency is unavailable. Avoid logging credentials or sensitive request data. Logging can help you establish that the class loaded, but it does not by itself prove that the intended streaming behaviour works correctly.
Build and package the module
Compile the source against the Wowza API and Java environment appropriate to the target installation, then package the resulting class files and any required dependencies in a JAR. Wowza’s documented procedure places the custom module JAR in [install-dir]/lib. Follow the packaging and dependency guidance for your particular Engine release; do not assume every library should be bundled in the same way or that a JAR built for one installation is portable to another.
There is no universal javac or Gradle command to copy here as a guaranteed build recipe. The official material reviewed does not establish one current command, dependency-coordinate set or Java compatibility matrix for every installation. Wowza identifies the Wowza IDE and a Gradle/Docker Compose guide as development routes, but you should verify their availability and requirements for the release you actually use. Oracle’s javac reference documents compiler options for Java, including module-path options; those Java Platform options do not turn module-info.java into a requirement for a Wowza server module.
Keep the build inputs reproducible. Note the Engine/API version, the Java version used to compile, the dependency versions and the contents of the JAR. If a build succeeds on a developer machine but fails on the server, compare those inputs before changing the code at random. A missing class can be a packaging or dependency issue; an incompatible method signature can instead reflect a mismatch between the code and the target API.
If your channel work is actually about playing a long video or playlist on YouTube rather than custom server-side application behaviour, look at the separate choices involved in setting up a 24/7 YouTube stream with FFmpeg in India. That is a different workflow from creating a Wowza module, but it can help clarify whether you need application code at all. Keep the systems separate in your plan: a Wowza module does not configure a YouTube channel or its live-stream settings by itself.
Configure it for the application
After placing the JAR in the installation’s lib directory, register the class with the application that should use it. In Wowza Streaming Engine Manager, open the target application’s Modules tab and add a module entry. Give it a unique name, add a description if useful, and enter the implementation’s fully qualified Java class name, including its package. The name and description help a person identify the entry; the fully qualified class name tells Wowza which class to load.
Check that the class name matches the package declaration and spelling in your source. For example, if the class is declared in package com.example.streaming, the registered name must include that package as well as the class name. A typo can look like a code failure even when the JAR is present. Keep a note of which application was changed so the restart and log review are aimed at the right target.
Wowza says that when a module is added while an application is running, you must restart that application for the change to take effect. If you modify an installed module, the documentation calls for restarting Wowza Streaming Engine. These instructions differ in scope: adding a module to a live application calls for an application restart, while a modified installed module calls for a server restart. Plan the maintenance impact before making either change, particularly if other applications share the Engine installation.
Configuration should follow the smallest scope that fulfils the requirement. Register the module only with the intended application, and do not treat a successful class load as a reason to attach it to every application. If the module uses external credentials or endpoint settings, keep those out of source control and follow the deployment’s approved secret-handling process. Validate configuration separately from code so a missing setting does not masquerade as a class-loading problem.
Test loading and troubleshoot
Test in stages. First verify that the JAR is in the expected installation location and that its class name matches the entry in the application’s Modules tab. Restart at the scope required by the change, then inspect the application or server logs for startup evidence and errors. If the module logs a clear startup message, that is evidence that the class was reached; next exercise the actual event or custom method and inspect the result. Do not claim successful runtime behaviour until that behaviour has been tested.
When loading fails, narrow the cause instead of changing several things at once. A class-not-found message suggests checking the JAR path, package, class name and dependency packaging. A method or linkage error points you towards API compatibility or mismatched dependencies. If the class loads but the intended action does not occur, confirm that you chose the right lifecycle hook, registered the correct application and invoked any custom method through the expected route. Record the Engine/API version and the exact log message before escalating to documentation or support.
External web-service calls need a separate check. Wowza warns that custom code making such calls on Streaming Engine 4.7.8 or later can encounter SSL handshake failures if the needed certificates are absent from the Java installation’s trust store. Verify the service’s certificate chain and identify the Java installation actually used by the Engine before changing trust configuration. The documented approach involves importing the service certificates into that Java installation’s cacerts keystore and restarting the service, but an older example path should not be copied without adapting it to the installation in use.
Treat trust-store changes as operational changes, not as a quick code fix. Confirm the certificate source, chain and destination keystore with the person responsible for the Engine environment, and retain a record of what was changed. A trust error can be distinct from an API or module-loading error; changing Java settings before confirming the cause can obscure the original failure and affect other applications.
A module is also not a general way to improve live playback quality. If the actual concern is a looping video stream, its encoding and delivery settings belong to a different troubleshooting path; the bitrate settings guide for a YouTube slideshow stream covers those choices. First identify whether the failure is in application code, the Engine’s connection to an external service, or the stream’s media and delivery configuration.
Operational choices before deployment
Before deploying beyond a test application, compare the extension options and their maintenance consequences. A module follows an application’s lifecycle and uses the streaming/application API surface. A listener is relevant to server lifecycle events; an HTTP provider is relevant when the interface is HTTP. The right answer depends on scope and interaction, not on which example has the shortest code.
| Decision | Application module | Listener or HTTP provider |
|---|---|---|
| Scope | Configured for a specific application | Consider when the requirement is server-wide or HTTP-facing |
| Interaction | Application and streaming APIs | Lifecycle events or HTTP request handling, depending on extension |
| Change impact | Adding it to a running application requires an application restart; modifying an installed module calls for a server restart | Check the matching extension documentation for its deployment and restart requirements |
| Compatibility check | Verify ModuleBase signatures and dependencies against the target Engine/API | Verify the corresponding API and lifecycle for the target release |
The table is a selection aid, not a complete compatibility specification. Confirm the exact deployment process for the extension you select in the documentation for your Engine release. If the requirement spans multiple applications or needs an HTTP surface, that is a reason to examine the other extension points before committing to an application module.
Document the deployment in a short handover: target application, JAR filename, fully qualified class name, build/API version, restart performed and the log evidence checked. Include a rollback route, such as restoring the prior JAR and configuration, consistent with your operational process. This is especially useful when the person who wrote the code is not the person who has to investigate a failure during a later maintenance window.
A small always-on channel may not need custom Wowza code. If the specific pain is leaving a computer running just to keep a file-based YouTube broadcast going, a cloud-run workflow can remove that local-computer burden: StreamNeo turns an uploaded video into a YouTube live stream that continues with your computer off, with monitoring and automatic restarts if it drops. It is YouTube-only and does not replace a Wowza application module when you need custom Wowza behaviour.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does a Wowza Java module need module-info.java?
Not ordinarily. A Wowza server-side module is a class extending ModuleBase, packaged and registered for an application. module-info.java belongs to Java’s separate named-module system and is not part of Wowza’s documented custom-module procedure.
Is onAppStart the same as a custom method?
No. onAppStart is an application lifecycle hook, while a custom method is callable behaviour you add for a particular task. Use the API version for your installed Engine to confirm the available signatures and how a custom method should be invoked.
Does adding the module require restarting the whole server?
Wowza’s instructions say to restart the application when adding a module while it is running. For a modified installed module, they call for restarting Streaming Engine; check the current documentation and plan for the relevant operational impact.
What should I check if an external web-service call fails with SSL?
Check the certificate chain and the Java installation used by the Engine, then verify whether the required certificates are present in its trust store. Wowza notes possible handshake failures for custom external-service calls on Engine 4.7.8 or later when certificates are missing; do not copy an old keystore path without checking the installation.