I had to post this.. so I apologize in advance

Image found on b3ta

First reason is their release of AIR 1.5 and its "run-ability" on my main system (WindowsXP x64). The OS is detected as Windows 2003 but it works, so thank you!
The second reason is their delivery on the original promise of Java (my fav dev language) to "run everywhere". I can write code in FlexBuilder and it will run on any operating system that supports Flash Player 9 or 10, this includes 64-bit Linux! For instance I wrote an application that uses a library / project called Merapi to capture desktop screen shots using AIR and Java which works on OSX and WindowsXP; I can also be certain that it works on Linux.

Go Adobe, Go!

I could have said one reason I hate the iPhone, but it is an awesome work of engineering and a fine gadget. So to get on with it... I hate them because of their draconian lock on the addition of applications / features. Its not about stability, its about greed; so stop lying Apple. I could rant for about an hour on this and other messed up things Apple does but I'll save it, since greed has little chance of going away. I'm posting this due to two articles I read this morning:

The bad: Why Apple Won't Allow Adobe Flash on iPhone

The good: Adobe Flash 10 running on Android G1 Google Phone

Needless to say, but I purchased a G1.

I saw a couple posts on Dvorak wherein the candidates were compared to trains and cars. This gave me an idea, what if we compared them with phones?

Update: For those of you who actually read the text - There are accusations in the comments that I "stole" this from Fark, I did not. The text clearly states where I got the idea from which is dvorak.org, a site I read daily. I never go to and never have been to the Fark forum, except to check the link in the comments. Those who know me, know this accusation is bull-crap and as stated if any accusers (loving their internet anonymity) want to bring it to me in person - I'm game.

I am so happy right now, Steven helped me with the MP4 branch and now it "works"!

After we worked out the time stamping and probable channel issues, it all came down to an SHA256 in the handshake routine. I still have a lot of clean up to do, but at least there is hope for 0.9.0 release

If you want alpha level code that only plays one clip, you can grab the branch from here: click

�

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.

A micro blackhole has caused a fault to form in the wall of the LHC, causing a ton of liquid Helium to spill into the tunnel. The loss of the coolant has forced a shutdown due to the over-heating of the supercooling magnets.
http://www.cnn.com/2008/TECH/science/09/20/hadron.collider.damage.ap/index.html

This is an experimental post, some of what you read in this post is fiction. Beat you to the punch Onion!

I have given up waiting for someone to claim the bounty or produce a fix for the web context logger issue. After much trouble tracking everything down, I have finally "fixed" the logging for web contexts, that is for those of you using the bootstrap method of server start up. The fixed revision is 3068 and its a little rough; meaning I still need to do bit of refactoring. I just wanted to let you all know.

Part 1

Here is what you have to put in your web.xml for each web application to get an individual logger context:

[listener]
[listener-class]org.red5.logging.ContextLoggingListener[/listener-class]
[/listener]

(more...)