Hi all, Just wanted apologise for my - stupid crossing posting with a personal message on the previous mail, not really sure how that happened :)
For all involved, Thanks and keep up the great work on the project - such an amazing tool, just finishing using it on a speeddating App, Cheers, Tommy ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, August 28, 2007 5:48 PM Subject: Red5 Digest, Vol 24, Issue 134 > Send Red5 mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://osflash.org/mailman/listinfo/red5_osflash.org > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Red5 digest..." > > > Today's Topics: > > 1. Re: WAR version and java 1.5 [SOLVED!?] (Paul deCoursey) > 2. Re: WAR version and java 1.5 [SOLVED!?] (Mauro Sanna) > 3. Re: WAR version and java 1.5 [SOLVED!?] (Paul deCoursey) > 4. Re: Red5 Digest, Vol 24, Issue 132 (Thomas Arnott) > 5. Re: WAR version and java 1.5 [SOLVED!?] (Mondain) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Aug 2007 09:24:31 -0500 > From: Paul deCoursey <[EMAIL PROTECTED]> > Subject: Re: [Red5] WAR version and java 1.5 [SOLVED!?] > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Ok, here is what I found. > > in the build.properties java.target_version was set to > ${java.specification.version}, which apparently isn't set to anything on > my system. When I replaced this value with 1.5 it built and will deploy > fine. I am guessing the release war was built with this same setting > and that is why it does not work. So if you can build your own, reset > that and it should work, if not then I can email you the war until > someone can update the released version. > > Paul > > > Lenny Sorey wrote: > > Hi Paul, > > > > I am using java 1.6 and have been for a very long time. > > > > Did you change your java version in the build.properties to 1.5. > > > > Do you have your java version defined in your environment variables. > > > > Variable Name: JAVA_VERSION > > Variable Value: 1.5 > > > > The reason I ask this is that there is also a java 1.5 piece in the > > War build > > but you must have the version defined in order for the proper jar > > files to be > > associated with your 1.5 war build. > > > > Regards, > > > > Lenny > > > > > > On 8/24/07, *Paul deCoursey* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > I have also had this problem. Something in the war version does not > > work on 1.5, but nobody seems to have answers. I spent 2 days > > trying to > > get it to work before I gave up. I'm using the standalone until I or > > someone else has a chance to fix the war version for 1.5. > > > > Paul > > > > > > Mauro Sanna wrote: > > > Il giorno ven, 24/08/2007 alle 08.20 +0200, vlado ha scritto: > > > > > >> I tried to build latest version of red5 from trunk with java > > 1.5 option > > >> in build.properties ( java.target_version=1.5 ). War file was > > created > > >> succesfully, but doesn't work. For example when I tried > > port_tester > > >> application, none port was tested successfully. > > >> > > > > > > My problem is the same, all the ports are connection failed. > > > > > > > > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 28 Aug 2007 18:08:27 +0200 > From: Mauro Sanna <[EMAIL PROTECTED]> > Subject: Re: [Red5] WAR version and java 1.5 [SOLVED!?] > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain > > Il giorno mar, 28/08/2007 alle 09.24 -0500, Paul deCoursey ha scritto: > > Ok, here is what I found. > > > > in the build.properties java.target_version was set to > > ${java.specification.version}, which apparently isn't set to anything on > > my system. When I replaced this value with 1.5 it built and will deploy > > fine. I am guessing the release war was built with this same setting > > and that is why it does not work. So if you can build your own, reset > > that and it should work, if not then I can email you the war until > > someone can update the released version. > > I don't build my version, I simply download the war version for java 5 > and deploy with tomcat, that's all. > The home page works but the oflaDemo don't work because rtmp doesn't > work. > > > > > > ------------------------------ > > Message: 3 > Date: Tue, 28 Aug 2007 11:33:16 -0500 > From: Paul deCoursey <[EMAIL PROTECTED]> > Subject: Re: [Red5] WAR version and java 1.5 [SOLVED!?] > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Here is the build I made that works for me. > > http://www.decoursey.net/red5.war > > (I can't afford a lot of bandwidth so don't download this if you don't > need it) > > > Paul > > Mauro Sanna wrote: > > Il giorno mar, 28/08/2007 alle 09.24 -0500, Paul deCoursey ha scritto: > > > >> Ok, here is what I found. > >> > >> in the build.properties java.target_version was set to > >> ${java.specification.version}, which apparently isn't set to anything on > >> my system. When I replaced this value with 1.5 it built and will deploy > >> fine. I am guessing the release war was built with this same setting > >> and that is why it does not work. So if you can build your own, reset > >> that and it should work, if not then I can email you the war until > >> someone can update the released version. > >> > > > > I don't build my version, I simply download the war version for java 5 > > and deploy with tomcat, that's all. > > The home page works but the oflaDemo don't work because rtmp doesn't > > work. > > > > > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > ------------------------------ > > Message: 4 > Date: Tue, 28 Aug 2007 17:42:54 +0100 > From: "Thomas Arnott" <[EMAIL PROTECTED]> > Subject: Re: [Red5] Red5 Digest, Vol 24, Issue 132 > To: <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > yep thats fine. > > But thining about it I may have actually saved it on the i drive in: > > i drive. > bms > public > tommy > > But if its not there give me a call on Thursday at some point - I'll be > around till about 2 > > Tommy > > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, August 28, 2007 1:27 PM > Subject: Red5 Digest, Vol 24, Issue 132 > > > > Send Red5 mailing list submissions to > > [email protected] > > > > To subscribe or unsubscribe via the World Wide Web, visit > > http://osflash.org/mailman/listinfo/red5_osflash.org > > or, via email, send a message with subject or body 'help' to > > [EMAIL PROTECTED] > > > > You can reach the person managing the list at > > [EMAIL PROTECTED] > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Red5 digest..." > > > > > > Today's Topics: > > > > 1. Re: Shared Object vs. invoke (Storm) > > 2. Re: Shared Object vs. invoke (Naicu Octavian) > > 3. problems when sending ByteArray to RED (Stanis?aw Fiedor) > > 4. Re: Shared Object vs. invoke (Mike) > > 5. Re: Shared Object vs. invoke (Naicu Octavian) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 28 Aug 2007 08:32:58 +0200 > > From: Storm <[EMAIL PROTECTED]> > > Subject: Re: [Red5] Shared Object vs. invoke > > To: [email protected] > > Message-ID: > > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="iso-8859-1" > > > > I agree with everything said here, but i must add something to defend poor > > nc.call's :) > > > > SOs may have a bad behaviour in some extreme cases such as updating right > > before disconnecting and such. I've had to change some functionality from > > SOs to nc.calls due to this, those "few bytes" of the callbacks are pretty > > useful to ensure that the update has been really recieved. Therefor > > everything has its place, even in a one-to-all update scenario. > > > > Cheers > > > > On 8/28/07, Joachim Bauch <[EMAIL PROTECTED]> wrote: > > > > > > Dominick Accattato schrieb: > > > [...] > > > > Now, if you were talking about using the SharedObject.send method, you > > > > may not need to bubble up to your application code, but your still > being > > > > sent to all the clients. That being said, you should just use the > > > > sharedObjects sync functionality anyway. > > > > > > using so.send or SO syncs even saves you a few bytes bandwidth as for > > > nc.call, the client sends back the result of the method call to the > > > server (or the server back to the client) which isn't done for SO > events. > > > Well, just a few bytes ;) but if you have lots of calls... > > > > > > Joachim > > > > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > -- > > ------------------------------------------------------------------- > > If a man speaks in a forest and his wife is not there, is he still wrong? > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/9567b85d/ > attachment-0001.html > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 28 Aug 2007 11:23:45 +0300 > > From: "Naicu Octavian" <[EMAIL PROTECTED]> > > Subject: Re: [Red5] Shared Object vs. invoke > > To: [email protected] > > Message-ID: > > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="utf-8" > > > > >I agree with everything said here, but i must add something to defend > poor > > nc.call's :) > > > > Another thing is that with nc.call calls for the server to the clients you > > can target specific clients. A ns.send sends the info to all clients > > subscribed to that SO. This is a more general issue but good to have in > mind > > when one is developing a private messages feature for example! :) > > > > -- > > Naicu Octavian, > > Project Manager for AVChat > > http://www.avchat.net > > > > On 28/08/07, Storm <[EMAIL PROTECTED]> wrote: > > > > > > I agree with everything said here, but i must add something to defend > poor > > > nc.call's :) > > > > > > SOs may have a bad behaviour in some extreme cases such as updating > right > > > before disconnecting and such. I've had to change some functionality > from > > > SOs to nc.calls due to this, those "few bytes" of the callbacks are > pretty > > > useful to ensure that the update has been really recieved. Therefor > > > everything has its place, even in a one-to-all update scenario. > > > > > > Cheers > > > > > > On 8/28/07, Joachim Bauch <[EMAIL PROTECTED]> wrote: > > > > > > > > Dominick Accattato schrieb: > > > > [...] > > > > > Now, if you were talking about using the SharedObject.send method, > you > > > > > may not need to bubble up to your application code, but your still > > > > being > > > > > sent to all the clients. That being said, you should just use the > > > > > sharedObjects sync functionality anyway. > > > > > > > > using so.send or SO syncs even saves you a few bytes bandwidth as for > > > > nc.call, the client sends back the result of the method call to the > > > > server (or the server back to the client) which isn't done for SO > > > > events. > > > > Well, just a few bytes ;) but if you have lots of calls... > > > > > > > > Joachim > > > > > > > > > > > > _______________________________________________ > > > > Red5 mailing list > > > > [email protected] > > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > > -- > > > ------------------------------------------------------------------- > > > If a man speaks in a forest and his wife is not there, is he still > wrong? > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/a56d9e84/ > attachment-0001.html > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 28 Aug 2007 12:21:18 +0200 > > From: Stanis?aw Fiedor <[EMAIL PROTECTED]> > > Subject: [Red5] problems when sending ByteArray to RED > > To: <[email protected]> > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="utf-8" > > > > Hi, > > I'm passing a function in flex to call it on the RED5 server with a > parametr which is of the ByteArray type. > (nc.call("myFunc",null,aByteArray);) > > Unfortunately I'm getting an error: > > > > INFO] 2007-08-28 12:09:40,859 SocketAcceptorIoProcessor-0.1:( > org.red5.io.amf3.Input.readDataType ) Unknown datatype: 12 > > [ERROR] 2007-08-28 12:09:40,859 SocketAcceptorIoProcessor-0.1:( > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeBuffer ) Error > decoding buffer > > org.red5.server.net.protocol.ProtocolException: Error during decoding > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decode(RTMPProtocolDecode > r.java:201) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeBuffer(RTMPProtocol > Decoder.java:121) > > at > org.red5.server.net.rtmp.codec.RTMPMinaProtocolDecoder.decode(RTMPMinaProtoc > olDecoder.java:60) > > at > org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCod > ecFilter.java:156) > > at > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived > (AbstractIoFilterChain.java:299) > > at > org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoF > ilterChain.java:53) > > at > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageRece > ived(AbstractIoFilterChain.java:648) > > at > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageRecei > ved(AbstractIoFilterChain.java:499) > > at > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived > (AbstractIoFilterChain.java:299) > > at > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageReceived(Abs > tractIoFilterChain.java:293) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.read(SocketIoProcesso > r.java:211) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.process(SocketIoProce > ssor.java:181) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoPr > ocessor.java:44) > > at > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoPr > ocessor.java:448) > > at > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java: > 39) > > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) > > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > > at java.lang.Thread.run(Unknown Source) > > Caused by: java.lang.IllegalArgumentException > > at java.nio.Buffer.limit(Unknown Source) > > at org.red5.io.amf.Input.readString(Input.java:227) > > at org.red5.io.object.Deserializer.deserialize(Deserializer.java:68) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeFlexMessage(RTMPPro > tocolDecoder.java:870) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodeMessage(RTMPProtoco > lDecoder.java:542) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decodePacket(RTMPProtocol > Decoder.java:405) > > at > org.red5.server.net.rtmp.codec.RTMPProtocolDecoder.decode(RTMPProtocolDecode > r.java:187) > > ... 17 more > > Well... does RED5 actually support bytearrays? - Cause amfphp does... so I > guess that red should also... has anybody a clue? > > > > BR > > > > stf > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/68c26270/ > attachment-0001.html > > > > ------------------------------ > > > > Message: 4 > > Date: Tue, 28 Aug 2007 08:11:59 -0400 > > From: Mike <[EMAIL PROTECTED]> > > Subject: Re: [Red5] Shared Object vs. invoke > > To: [email protected] > > Message-ID: <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > Good point, Octavian. > > Suppose I only want to send position data to players that are within a > > certain range. > > > > For example, anyone within 100 "meters". > > > > SharedObjects don't really give me that luxury, do they? > > I may be forced to use nc.call? > > Or, is there another method? > > > > Is there a version of nc.call that does NOT require a return message? > > > > Naicu Octavian wrote: > > > >I agree with everything said here, but i must add something to defend > > > poor nc.call's :) > > > > > > Another thing is that with nc.call calls for the server to the clients > > > you can target specific clients. A ns.send sends the info to all > > > clients subscribed to that SO. This is a more general issue but good > > > to have in mind when one is developing a private messages feature for > > > example! :) > > > > > > -- > > > Naicu Octavian, > > > Project Manager for AVChat > > > http://www.avchat.net > > > > > > On 28/08/07, *Storm* <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > I agree with everything said here, but i must add something to > > > defend poor nc.call's :) > > > > > > SOs may have a bad behaviour in some extreme cases such as > > > updating right before disconnecting and such. I've had to change > > > some functionality from SOs to nc.calls due to this, those "few > > > bytes" of the callbacks are pretty useful to ensure that the > > > update has been really recieved. Therefor everything has its > > > place, even in a one-to-all update scenario. > > > > > > Cheers > > > > > > > > > On 8/28/07, *Joachim Bauch* < [EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > Dominick Accattato schrieb: > > > [...] > > > > Now, if you were talking about using the SharedObject.send > > > method, you > > > > may not need to bubble up to your application code, but your > > > still being > > > > sent to all the clients. That being said, you should just > > > use the > > > > sharedObjects sync functionality anyway. > > > > > > using so.send or SO syncs even saves you a few bytes bandwidth > > > as for > > > nc.call, the client sends back the result of the method call > > > to the > > > server (or the server back to the client) which isn't done for > > > SO events. > > > Well, just a few bytes ;) but if you have lots of calls... > > > > > > Joachim > > > > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] <mailto:[email protected]> > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > -- > > ------------------------------------------------------------------- > > > If a man speaks in a forest and his wife is not there, is he still > > > wrong? > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] <mailto:[email protected]> > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Tue, 28 Aug 2007 15:27:31 +0300 > > From: "Naicu Octavian" <[EMAIL PROTECTED]> > > Subject: Re: [Red5] Shared Object vs. invoke > > To: [email protected] > > Message-ID: > > <[EMAIL PROTECTED]> > > Content-Type: text/plain; charset="utf-8" > > > > >Suppose I only want to send position data to players that are within a > > certain range. For example, anyone within 100 "meters". > > > > Your mileage will vary. If you have 1000 connected users and in each 100m > > radius there are only 10 users then nc.call can be a good decision! but in > > such a case you can also have a SO for each 100mx100m sqare radius,etc... > > .Depends on what you are trying to do! > > > > On 28/08/07, Mike <[EMAIL PROTECTED]> wrote: > > > > > > Good point, Octavian. > > > Suppose I only want to send position data to players that are within a > > > certain range. > > > > > > For example, anyone within 100 "meters". > > > > > > SharedObjects don't really give me that luxury, do they? > > > I may be forced to use nc.call? > > > Or, is there another method? > > > > > > Is there a version of nc.call that does NOT require a return message? > > > > > > Naicu Octavian wrote: > > > > >I agree with everything said here, but i must add something to defend > > > > poor nc.call's :) > > > > > > > > Another thing is that with nc.call calls for the server to the clients > > > > you can target specific clients. A ns.send sends the info to all > > > > clients subscribed to that SO. This is a more general issue but good > > > > to have in mind when one is developing a private messages feature for > > > > example! :) > > > > > > > > -- > > > > Naicu Octavian, > > > > Project Manager for AVChat > > > > http://www.avchat.net > > > > > > > > On 28/08/07, *Storm* <[EMAIL PROTECTED] > > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > > I agree with everything said here, but i must add something to > > > > defend poor nc.call's :) > > > > > > > > SOs may have a bad behaviour in some extreme cases such as > > > > updating right before disconnecting and such. I've had to change > > > > some functionality from SOs to nc.calls due to this, those "few > > > > bytes" of the callbacks are pretty useful to ensure that the > > > > update has been really recieved. Therefor everything has its > > > > place, even in a one-to-all update scenario. > > > > > > > > Cheers > > > > > > > > > > > > On 8/28/07, *Joachim Bauch* < [EMAIL PROTECTED] > > > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > > Dominick Accattato schrieb: > > > > [...] > > > > > Now, if you were talking about using the SharedObject.send > > > > method, you > > > > > may not need to bubble up to your application code, but your > > > > still being > > > > > sent to all the clients. That being said, you should just > > > > use the > > > > > sharedObjects sync functionality anyway. > > > > > > > > using so.send or SO syncs even saves you a few bytes bandwidth > > > > as for > > > > nc.call, the client sends back the result of the method call > > > > to the > > > > server (or the server back to the client) which isn't done for > > > > SO events. > > > > Well, just a few bytes ;) but if you have lots of calls... > > > > > > > > Joachim > > > > > > > > > > > > _______________________________________________ > > > > Red5 mailing list > > > > [email protected] <mailto:[email protected]> > > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > > > > > > -- > > > > ------------------------------------------------------------------- > > > > If a man speaks in a forest and his wife is not there, is he still > > > > wrong? > > > > > > > > _______________________________________________ > > > > Red5 mailing list > > > > [email protected] <mailto:[email protected]> > > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > Red5 mailing list > > > > [email protected] > > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/9e1ee68a/ > attachment.html > > > > ------------------------------ > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > End of Red5 Digest, Vol 24, Issue 132 > > ************************************* > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.484 / Virus Database: 269.12.10/976 - Release Date: > 27/08/2007 18:20 > > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 28 Aug 2007 09:48:26 -0700 > From: Mondain <[EMAIL PROTECTED]> > Subject: Re: [Red5] WAR version and java 1.5 [SOLVED!?] > To: [email protected] > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > Paul, you should use a free filehost (http://www.mediafire.com/); I have put > this on mediafire for you.. this war has not been tested by the team nor was > it built by us.. use at your own risk :) > > http://www.mediafire.com/?9gnfscsddjm > > > > On 8/28/07, Paul deCoursey <[EMAIL PROTECTED]> wrote: > > > > Here is the build I made that works for me. > > > > http://www.decoursey.net/red5.war > > > > (I can't afford a lot of bandwidth so don't download this if you don't > > need it) > > > > > > Paul > > > > Mauro Sanna wrote: > > > Il giorno mar, 28/08/2007 alle 09.24 -0500, Paul deCoursey ha scritto: > > > > > >> Ok, here is what I found. > > >> > > >> in the build.properties java.target_version was set to > > >> ${java.specification.version}, which apparently isn't set to anything > > on > > >> my system. When I replaced this value with 1.5 it built and will deploy > > >> fine. I am guessing the release war was built with this same setting > > >> and that is why it does not work. So if you can build your own, reset > > >> that and it should work, if not then I can email you the war until > > >> someone can update the released version. > > >> > > > > > > I don't build my version, I simply download the war version for java 5 > > > and deploy with tomcat, that's all. > > > The home page works but the oflaDemo don't work because rtmp doesn't > > > work. > > > > > > > > > > > > _______________________________________________ > > > Red5 mailing list > > > [email protected] > > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > > > > > > > _______________________________________________ > > Red5 mailing list > > [email protected] > > http://osflash.org/mailman/listinfo/red5_osflash.org > > > > > > -- > It is difficult to free fools from the chains they revere. - Voltaire > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://osflash.org/pipermail/red5_osflash.org/attachments/20070828/6ce84557/ attachment.html > > ------------------------------ > > _______________________________________________ > Red5 mailing list > [email protected] > http://osflash.org/mailman/listinfo/red5_osflash.org > > > End of Red5 Digest, Vol 24, Issue 134 > ************************************* > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.484 / Virus Database: 269.12.10/976 - Release Date: 27/08/2007 18:20 > _______________________________________________ Red5 mailing list [email protected] http://osflash.org/mailman/listinfo/red5_osflash.org
