You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Taylor Mathewson <ta...@gmail.com> on 2009/11/21 00:18:41 UTC
Flash Served from Tapestry Context Not Playing
Hi all,
I found a possible problem and a workaround, and I just want to put it up
here in case anyone else encounters a similar problem.
I have a Flex3 element embedded in a page. It would load, but it wouldn't
run. We stripped it down to a very simple app (hello world), but it still
wouldn't run.
Right clicking on the flash element showed the problem: the "Play" item was
unchecked on the flash player context menu. Selecting it would run the flex
piece as expected, but reloading the page, it would again not play.
Accessing the swf directly yielded strange results.
Going through a standard path (e.g.
http://localhost:8080/appName/swf/myFlex.swf) worked fine but going through
Tapestry's context (e.g.
http://localhost:8080/appName/assets/ctx/631103cab3b12068/swf/myFlex.swf)
would load the component but not play it.
This offers with one option; link to all flash components directly.
However, the tapestry context urls present a nice solution to avoiding
cached older versions of flash elements, without forcing a client to
re-download on every view.
The other solution I found was to disable GZIP on
application/x-shockwave-flash by contributing that content type to the
responsecompressionanalyzer
I'm not sure why this happens, and it seems not to happen with
flash-authored pieces, as opposed to flex-authored, even when they are
published with the same player version etc... and why it happens only in the
tapestry context path (according to LiveHTTP, both had gzip compression, but
the tapestry context had a content-length about 25 bytes higher).
Just hoping to save others the couple hours of "wtf" I just went through.
Thanks,
Taylor
Re: Flash Served from Tapestry Context Not Playing
Posted by Howard Lewis Ship <hl...@gmail.com>.
Then that should definitely be the default.
On Mon, Nov 23, 2009 at 1:47 AM, Ben Gidley <be...@gidley.co.uk> wrote:
> I have also seen this locally so I don't believe it is proxy - I just add
> flash to non-gzippable types.
>
>
>
> Ben Gidley
>
> www.gidley.co.uk
> ben@gidley.co.uk
>
>
> On Sun, Nov 22, 2009 at 12:16 PM, Howard Lewis Ship <hl...@gmail.com>wrote:
>
>> On Fri, Nov 20, 2009 at 3:18 PM, Taylor Mathewson
>> <ta...@gmail.com> wrote:
>> > Hi all,
>> >
>> > I found a possible problem and a workaround, and I just want to put it up
>> > here in case anyone else encounters a similar problem.
>> >
>> > I have a Flex3 element embedded in a page. It would load, but it
>> wouldn't
>> > run. We stripped it down to a very simple app (hello world), but it
>> still
>> > wouldn't run.
>> >
>> > Right clicking on the flash element showed the problem: the "Play" item
>> was
>> > unchecked on the flash player context menu. Selecting it would run the
>> flex
>> > piece as expected, but reloading the page, it would again not play.
>> >
>> > Accessing the swf directly yielded strange results.
>> >
>> > Going through a standard path (e.g.
>> > http://localhost:8080/appName/swf/myFlex.swf) worked fine but going
>> through
>> > Tapestry's context (e.g.
>> > http://localhost:8080/appName/assets/ctx/631103cab3b12068/swf/myFlex.swf
>> )
>> > would load the component but not play it.
>> >
>> > This offers with one option; link to all flash components directly.
>> > However, the tapestry context urls present a nice solution to avoiding
>> > cached older versions of flash elements, without forcing a client to
>> > re-download on every view.
>> >
>> > The other solution I found was to disable GZIP on
>> > application/x-shockwave-flash by contributing that content type to the
>> > responsecompressionanalyzer
>>
>> Could a server in between Tapestry and the client be re-gzipping or
>> otherwise corrupting the bytestream?
>>
>> In any case, I suspect adding flash as a non-compressable type would
>> be a good idea; a JIRA issue would be appreciated.
>>
>> >
>> > I'm not sure why this happens, and it seems not to happen with
>> > flash-authored pieces, as opposed to flex-authored, even when they are
>> > published with the same player version etc... and why it happens only in
>> the
>> > tapestry context path (according to LiveHTTP, both had gzip compression,
>> but
>> > the tapestry context had a content-length about 25 bytes higher).
>> >
>> > Just hoping to save others the couple hours of "wtf" I just went through.
>> >
>> > Thanks,
>> > Taylor
>> >
>>
>>
>>
>> --
>> Howard M. Lewis Ship
>>
>> Creator of Apache Tapestry
>>
>> The source for Tapestry training, mentoring and support. Contact me to
>> learn how I can get you up and productive in Tapestry fast!
>>
>> (971) 678-5210
>> http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Flash Served from Tapestry Context Not Playing
Posted by Ben Gidley <be...@gidley.co.uk>.
I have also seen this locally so I don't believe it is proxy - I just add
flash to non-gzippable types.
Ben Gidley
www.gidley.co.uk
ben@gidley.co.uk
On Sun, Nov 22, 2009 at 12:16 PM, Howard Lewis Ship <hl...@gmail.com>wrote:
> On Fri, Nov 20, 2009 at 3:18 PM, Taylor Mathewson
> <ta...@gmail.com> wrote:
> > Hi all,
> >
> > I found a possible problem and a workaround, and I just want to put it up
> > here in case anyone else encounters a similar problem.
> >
> > I have a Flex3 element embedded in a page. It would load, but it
> wouldn't
> > run. We stripped it down to a very simple app (hello world), but it
> still
> > wouldn't run.
> >
> > Right clicking on the flash element showed the problem: the "Play" item
> was
> > unchecked on the flash player context menu. Selecting it would run the
> flex
> > piece as expected, but reloading the page, it would again not play.
> >
> > Accessing the swf directly yielded strange results.
> >
> > Going through a standard path (e.g.
> > http://localhost:8080/appName/swf/myFlex.swf) worked fine but going
> through
> > Tapestry's context (e.g.
> > http://localhost:8080/appName/assets/ctx/631103cab3b12068/swf/myFlex.swf
> )
> > would load the component but not play it.
> >
> > This offers with one option; link to all flash components directly.
> > However, the tapestry context urls present a nice solution to avoiding
> > cached older versions of flash elements, without forcing a client to
> > re-download on every view.
> >
> > The other solution I found was to disable GZIP on
> > application/x-shockwave-flash by contributing that content type to the
> > responsecompressionanalyzer
>
> Could a server in between Tapestry and the client be re-gzipping or
> otherwise corrupting the bytestream?
>
> In any case, I suspect adding flash as a non-compressable type would
> be a good idea; a JIRA issue would be appreciated.
>
> >
> > I'm not sure why this happens, and it seems not to happen with
> > flash-authored pieces, as opposed to flex-authored, even when they are
> > published with the same player version etc... and why it happens only in
> the
> > tapestry context path (according to LiveHTTP, both had gzip compression,
> but
> > the tapestry context had a content-length about 25 bytes higher).
> >
> > Just hoping to save others the couple hours of "wtf" I just went through.
> >
> > Thanks,
> > Taylor
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: Flash Served from Tapestry Context Not Playing
Posted by Howard Lewis Ship <hl...@gmail.com>.
On Fri, Nov 20, 2009 at 3:18 PM, Taylor Mathewson
<ta...@gmail.com> wrote:
> Hi all,
>
> I found a possible problem and a workaround, and I just want to put it up
> here in case anyone else encounters a similar problem.
>
> I have a Flex3 element embedded in a page. It would load, but it wouldn't
> run. We stripped it down to a very simple app (hello world), but it still
> wouldn't run.
>
> Right clicking on the flash element showed the problem: the "Play" item was
> unchecked on the flash player context menu. Selecting it would run the flex
> piece as expected, but reloading the page, it would again not play.
>
> Accessing the swf directly yielded strange results.
>
> Going through a standard path (e.g.
> http://localhost:8080/appName/swf/myFlex.swf) worked fine but going through
> Tapestry's context (e.g.
> http://localhost:8080/appName/assets/ctx/631103cab3b12068/swf/myFlex.swf)
> would load the component but not play it.
>
> This offers with one option; link to all flash components directly.
> However, the tapestry context urls present a nice solution to avoiding
> cached older versions of flash elements, without forcing a client to
> re-download on every view.
>
> The other solution I found was to disable GZIP on
> application/x-shockwave-flash by contributing that content type to the
> responsecompressionanalyzer
Could a server in between Tapestry and the client be re-gzipping or
otherwise corrupting the bytestream?
In any case, I suspect adding flash as a non-compressable type would
be a good idea; a JIRA issue would be appreciated.
>
> I'm not sure why this happens, and it seems not to happen with
> flash-authored pieces, as opposed to flex-authored, even when they are
> published with the same player version etc... and why it happens only in the
> tapestry context path (according to LiveHTTP, both had gzip compression, but
> the tapestry context had a content-length about 25 bytes higher).
>
> Just hoping to save others the couple hours of "wtf" I just went through.
>
> Thanks,
> Taylor
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org