I recall seeing a question from a user about accessing servlet parameters from their Red5 application, so I have created a small demo which shows how to not only access sevlet parameters from Red5 apps but the other way around as well.

Retrieve a servlet context parameter from inside a Red5 application (AppContext -> Servlet)

1. Grab a reference to the application context

ApplicationContext appCtx = getContext().getApplicationContext();

2. Get the servlet context

ServletContext ctx = ((XmlWebApplicationContext) appCtx).getServletContext();

3. Get the context parameter

String param = ctx.getInitParameter("myparam");

Retrieve an application context parameter from a inside a servlet (Servlet -> AppContext)

1. Get the servlet context

ServletContext ctx = getServletContext();

2. Grab a reference to the application context

ApplicationContext appCtx = ctx.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);

3. Get the bean holding the parameter

MyBean bean = appCtx.getBean("mybean");
String param = bean.getParameter("myparam");

Sample project files: parameterdemo.zip

Instructions:

Unzip the demo and create a new directory named parameterdemo in your red5/webapps directory, then restart your server.

Open your browser and go here: http://localhost/parameterdemo/myservlet?paramName=myparam

You should see "Hello World"

To test the Red5 application you will need to create a Flex or Flash application that connects to: rtmp://localhost/parameterdemo

Then simply call "getParameter" passing a parameter name you want the value of. The name must match a context param in the web.xml file.

�

I just spent many hours trying to get the Admin (demo) application working properly; it was quite painful. Trying to get JNDI and Spring to cooperate in an Embedded Tomcat instance is not what I call fun, but I have it working alright for now. There still seem to be some underlying classloader issues in the server, because I cannot self-contain the web applications. No matter how I configure the server or application, there are always jars that must be in the shared lib directory; if anyone has any experience with this I would love to hear it.  So without further rambling, here are the steps to take to get it working:

1. Obtain the admin war or use my archive

2. Unzip the archive into the webapps directory (red5/webapps/admin)

3. Move the following jars to your shared lib directory (red5/lib)

• derby-10.4.2.0.jar
• jasper-el-6.0.18.jar
• el-api.jar
• simple-jndi-0.11.4.1.jar
• spring-jdbc-2.5.5.jar
• spring-orm-2.5.5.jar
• spring-tx-2.5.5.jar

4. Restart Red5

5. Go to http://localhost:5080/admin/register.html to add new users

I hope this helps those of you new to red5, since I know it can be difficult to get things going at times.

Here is my test version zipped for your convenience: admin_10012008.zip (1.02Mb)

In Red5, you have pretty much full access to manipulate the embedded Tomcat engine via Spring. With that being said I would like to give details on how to change the http connector between two available options; there are several other options, but I'll only be covering NIO and BIO. First a quick explanation of these two options:

• BIO - Blocking Input / Output, this has been around since the beginning of internet time. It uses one thread per socket connnection to handle requests.
• NIO - Non-blocking Input / Output, this has been available in the JDK since 1.4. It uses a single thread to handle many socket connections.

I created a post about this subject almost a year ago, but there were a couple minor issues with the examples. Here I will show what eight additional months of experience can provide. The example provided here uses a custom object in Flex to pass information to and from the server, which in this case will be Red5. If one of you has an example which uses FMS on the server-side, I would be glad to include it here.
(more...)

Sorry for the delay in posting this, but I was a tad busy with the svn sync
I also had some trouble getting the IvyDE to behave as I expected. The screen cast below will show you how to get Red5 to build properly in Eclipse. One of the key points is to use Ant from a console to pull any suborn libraries down into the correct location, to do this simply turn off the auto build in your eclipse project and use this command:
ant -Divy.conf.name="java6, eclipse" dist
Note: substitute java5 for java6 if you are using JDK 1.5.
When you've finished using ant, remember to turn auto-build back on.


(more...)

Some of you may know that there are at least two different versions of the IvyDE, the plugin which interfaces Eclipse with your Ivy files. To use the plugin with Red5 you will need the latest version, especially if you use Ganymede. I will record some screen casts to help you through the upgrade / fixes. I apologize now for my large screen size, I will record smaller versions in the future. So without further rambling here is the first video: IvyDE part 1

I recently needed to convert some C / C++ code to Java and I remembered a couple utilities which are supposed to do the conversion for you. These tools under the name C2J aren't especially useful in my case but they are difficult to find so I am making them available here. There are two versions:

• c2java - This is the first-cut I believe
• c2jGNU - This appears to be more robust

I tried to contact the authors before posting this, but they have yet to respond. I take no responsiblity for these tools so use them at your own risk.

The first step to perform when using JMX in Red5 is to get the MBeanServer. Once you have a server instance you may look up, create, register, and unregister mbeans. MBeans provide access to methods on classes which implement the associated MBean interface, most of the details about this are beyond the scope of this post. Today, we will cover the loading and unloading of a Red5 context.

 
    MBeanServer mbs = JMXFactory.getMBeanServer();
    ObjectName oName = JMXFactory.createObjectName("type", "ContextLoader");
    ContextLoaderMBean contextLoader = null;
    if (mbs.isRegistered(oName)) {
        contextLoader = (ContextLoaderMBean) MBeanServerInvocationHandler.newProxyInstance
(mbs, oName, ContextLoaderMBean.class, true);
        System.out.println("Context loader was found");
    } else {
        System.err.println("Context loader was not found");
    }
 

Once you have the context loader you can load the context. The context in this case is a Red5 default context consisting of a group of web applications that have been Red5 enabled. To be Red5 enabled means that they have the proper configurations and a class extending org.red5.server.adapter.ApplicationAdapter.

 
    if (contextLoader != null) {
	contextLoader.loadContext("localhost", "c:/red5/webapps/red5-default.xml");
    }
 

To unload the context perform this step.

 
    if (contextLoader != null) {
	contextLoader.unloadContext("localhost");
    }
 

See how simple that is?

Please note that I do not condone the use of System.out as a substitute for proper logging