You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Joel Hill <Hi...@michigan.gov> on 2007/07/27 17:12:09 UTC
wicket-event.js returning unreadable
I'm using IHeaderContributor to include dynamic Javascript; however,
wicket-event.js is returning to the browser as unreadable garbage. I
think it MAY have something to do with compression. Our app uses a
home-grown compression filter, and I also read today that wicket uses
default compression too. I tried disabling one or the other or both but
this didn't work UNLESS I was using NetTool, which basically acts as a
request intercept that spits out the request/response headers. I
wouldn't expect NetTool to modify the request/response at all, but for
some reason if I have at least one of the compression filters disabled
AND go through NetTool wicket-event.js returns fine.
I also get this in my log output when the js file fails to return
properly:
DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
(locateByResourceFinder:197) - Attempting to locate resource
'org/apache/wicket/markup/html/wicket-event.js' on path [folders = [],
webapppaths: []]
DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
(locateByClassLoader:166) - Attempting to locate resource
'org/apache/wicket/markup/html/wicket-event.js' using classloader
mcir.root:0.0.0
DEBUG 2007-07-27 10:54:19,156 resource.UrlResourceStream (<init>:92) -
cannot convert url:
code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-Beta-20070606.jar!/org/apache/wicket/markup/html/wicket-event.js
to file (URI scheme is not "file"), falling back to the inputstream for
polling
What makes it even more odd is I've used IHeaderContributor in another,
far simpler app before and it's worked fine.
Thanks.
Joel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by hillj2 <Hi...@michigan.gov>.
Disabling wicket resource compression did not solve my issue, however I may
have a workaround that's faster than tinkering with oc4j's settings, which
I'm not an expert on. See my response to Alex's suggestion for details.
Joel
hillj2 wrote:
>
> I'm using OC4J 10.1.3.2, I believe it's 32-bit. I've tried it with both
> FF2 and IE6. I'm not sure about the response headers, because when I use
> my tool for extracting the headers (NetTool 4.7.0) it seems to work fine,
> so I'm not sure the headers are the same as when it doesn't work. Unless
> there's some simple thing I can override in wicket to intercept the
> response headers (which there probably is). Maybe that happens because
> technically NetTool becomes my webserver at that point (with oc4j being
> NetTool's webserver). That would seem to indicate even more that it's an
> Oracle problem.
>
> As for "junk" I mean the js file returns as random ascii, like it's binary
> data.
>
> I think I tried disabling wicket compression once before, with no success.
> But I'll try that again just to make sure. I'll also see if I can tinker
> with Oracle's settings.
>
> Thanks for the suggestions, I'll let you know how it works out.
>
> Joel
>
>
>
> Matej Knopp-2 wrote:
>>
>> Well, oracle app server doesn't have a good reputation exactly for
>> messing the output. Try disabling the compression of wicket resources
>> completely,
>>
>> Application.getResourceSettings.setDisableGZipCompression(true).
>>
>> -Matej
>>
>> On 8/3/07, Martijn Dashorst <ma...@gmail.com> wrote:
>>> Seems like Oracle application server, version 10.1, 32 bits?
>>>
>>> Apparently the classloader for the app server converts the
>>> getClass().getResourceAsStream("....wicket-event.js")
>>> to use a "code-source:" protocol. I'm not sure, but it sounds like a
>>> security constraint in your setup.
>>>
>>> Martijn
>>>
>>> On 8/3/07, Matej Knopp <ma...@gmail.com> wrote:
>>> > I doubt this is related. What app server are you using? What exactly
>>> > does it mean junk? Wha headers are set on ouput? What browser are you
>>> > using?
>>> >
>>> > -Matej
>>> >
>>
>>
>
--
View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12018236
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by hillj2 <Hi...@michigan.gov>.
I'm using OC4J 10.1.3.2, I believe it's 32-bit. I've tried it with both FF2
and IE6. I'm not sure about the response headers, because when I use my
tool for extracting the headers (NetTool 4.7.0) it seems to work fine, so
I'm not sure the headers are the same as when it doesn't work. Unless
there's some simple thing I can override in wicket to intercept the response
headers (which there probably is). Maybe that happens because technically
NetTool becomes my webserver at that point (with oc4j being NetTool's
webserver). That would seem to indicate even more that it's an Oracle
problem.
As for "junk" I mean the js file returns as random ascii, like it's binary
data.
I think I tried disabling wicket compression once before, with no success.
But I'll try that again just to make sure. I'll also see if I can tinker
with Oracle's settings.
Thanks for the suggestions, I'll let you know how it works out.
Joel
Matej Knopp-2 wrote:
>
> Well, oracle app server doesn't have a good reputation exactly for
> messing the output. Try disabling the compression of wicket resources
> completely,
>
> Application.getResourceSettings.setDisableGZipCompression(true).
>
> -Matej
>
> On 8/3/07, Martijn Dashorst <ma...@gmail.com> wrote:
>> Seems like Oracle application server, version 10.1, 32 bits?
>>
>> Apparently the classloader for the app server converts the
>> getClass().getResourceAsStream("....wicket-event.js")
>> to use a "code-source:" protocol. I'm not sure, but it sounds like a
>> security constraint in your setup.
>>
>> Martijn
>>
>> On 8/3/07, Matej Knopp <ma...@gmail.com> wrote:
>> > I doubt this is related. What app server are you using? What exactly
>> > does it mean junk? Wha headers are set on ouput? What browser are you
>> > using?
>> >
>> > -Matej
>> >
>
>
--
View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12015983
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by Matej Knopp <ma...@gmail.com>.
Well, oracle app server doesn't have a good reputation exactly for
messing the output. Try disabling the compression of wicket resources
completely,
Application.getResourceSettings.setDisableGZipCompression(true).
-Matej
On 8/3/07, Martijn Dashorst <ma...@gmail.com> wrote:
> Seems like Oracle application server, version 10.1, 32 bits?
>
> Apparently the classloader for the app server converts the
> getClass().getResourceAsStream("....wicket-event.js")
> to use a "code-source:" protocol. I'm not sure, but it sounds like a
> security constraint in your setup.
>
> Martijn
>
> On 8/3/07, Matej Knopp <ma...@gmail.com> wrote:
> > I doubt this is related. What app server are you using? What exactly
> > does it mean junk? Wha headers are set on ouput? What browser are you
> > using?
> >
> > -Matej
> >
> > On 8/3/07, hillj2 <Hi...@michigan.gov> wrote:
> > >
> > > I'm still having trouble getting wicket-event.js to return anything but junk.
> > > Even though I thought it might have something to do with compression, I
> > > doubt that now, because I have my homegrown compression filter turned off.
> > > Does anyone know what this error means:
> > >
> > > DEBUG 2007-08-03 15:42:34,452 resource.UrlResourceStream (<init>:92) -
> > > cannot convert url:
> > > code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-beta2.jar!/org/apache/wicket/markup/html/wicket-event.js
> > > to file (URI scheme is not "file"), falling back to the inputstream for
> > > polling
> > >
> > > I'm hoping it will give me some clue as to what is going on, but maybe it's
> > > just another by-product of the problem. Any suggestions were be great.
> > > Thanks.
> > >
> > > Joel
> > >
> > > --
> > > View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a11989377
> > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
>
> --
> Wicket joins the Apache Software Foundation as Apache Wicket
> Apache Wicket 1.3.0-beta2 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by Martijn Dashorst <ma...@gmail.com>.
Seems like Oracle application server, version 10.1, 32 bits?
Apparently the classloader for the app server converts the
getClass().getResourceAsStream("....wicket-event.js")
to use a "code-source:" protocol. I'm not sure, but it sounds like a
security constraint in your setup.
Martijn
On 8/3/07, Matej Knopp <ma...@gmail.com> wrote:
> I doubt this is related. What app server are you using? What exactly
> does it mean junk? Wha headers are set on ouput? What browser are you
> using?
>
> -Matej
>
> On 8/3/07, hillj2 <Hi...@michigan.gov> wrote:
> >
> > I'm still having trouble getting wicket-event.js to return anything but junk.
> > Even though I thought it might have something to do with compression, I
> > doubt that now, because I have my homegrown compression filter turned off.
> > Does anyone know what this error means:
> >
> > DEBUG 2007-08-03 15:42:34,452 resource.UrlResourceStream (<init>:92) -
> > cannot convert url:
> > code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-beta2.jar!/org/apache/wicket/markup/html/wicket-event.js
> > to file (URI scheme is not "file"), falling back to the inputstream for
> > polling
> >
> > I'm hoping it will give me some clue as to what is going on, but maybe it's
> > just another by-product of the problem. Any suggestions were be great.
> > Thanks.
> >
> > Joel
> >
> > --
> > View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a11989377
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Wicket joins the Apache Software Foundation as Apache Wicket
Apache Wicket 1.3.0-beta2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta2/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by Matej Knopp <ma...@gmail.com>.
I doubt this is related. What app server are you using? What exactly
does it mean junk? Wha headers are set on ouput? What browser are you
using?
-Matej
On 8/3/07, hillj2 <Hi...@michigan.gov> wrote:
>
> I'm still having trouble getting wicket-event.js to return anything but junk.
> Even though I thought it might have something to do with compression, I
> doubt that now, because I have my homegrown compression filter turned off.
> Does anyone know what this error means:
>
> DEBUG 2007-08-03 15:42:34,452 resource.UrlResourceStream (<init>:92) -
> cannot convert url:
> code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-beta2.jar!/org/apache/wicket/markup/html/wicket-event.js
> to file (URI scheme is not "file"), falling back to the inputstream for
> polling
>
> I'm hoping it will give me some clue as to what is going on, but maybe it's
> just another by-product of the problem. Any suggestions were be great.
> Thanks.
>
> Joel
>
> --
> View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a11989377
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by hillj2 <Hi...@michigan.gov>.
I'm still having trouble getting wicket-event.js to return anything but junk.
Even though I thought it might have something to do with compression, I
doubt that now, because I have my homegrown compression filter turned off.
Does anyone know what this error means:
DEBUG 2007-08-03 15:42:34,452 resource.UrlResourceStream (<init>:92) -
cannot convert url:
code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-beta2.jar!/org/apache/wicket/markup/html/wicket-event.js
to file (URI scheme is not "file"), falling back to the inputstream for
polling
I'm hoping it will give me some clue as to what is going on, but maybe it's
just another by-product of the problem. Any suggestions were be great.
Thanks.
Joel
--
View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a11989377
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by hillj2 <Hi...@michigan.gov>.
I believe I've finally solved my problem.
No doubt the original problem was double compression resulting from using a
homegrown compression filter on top of wicket's default compression. After
being forced to look at this issue again, which suddenly seemed to not only
be a problem with just IE (FF suddenly seemed to work fine) but only with
the IE on MY computer, I ended up clearing IE's temporary internet files.
Problem solved. So IE cached the double compressed version of the js file
and kept it in cache for several weeks until I manually deleted it.
For now it's looking like the problem is solved. (Thanks, Microsoft, for
introducing the world to permanent temporary internet files.)
Joel
--
View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12478274
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by Alex Objelean <al...@isdc.ro>.
This way you end up not using compression at all? I would be interested in a
solution which would help me to use the compression without any problems.
Maybe someone from the wicket core team would help us to understand the
difference between using IHeaderContributor and adding directly
JavascriptReference as a behavior?
The problem can reproduced by adding
http://sourceforge.net/project/showfiles.php?group_id=195642 Resource
Accelerate to a simple project, include js using both methods, and see what
is the server response (using firebug or any other tool).
hillj2 wrote:
>
> Well I have the compression filter turned off now, so that shouldn't be
> the problem. And I'm not trying to dynamically include a js file, but
> create dynamic js which runs onload:
>
> response.renderOnLoadJavascript("some js code");
>
> However, your suggestion inspired me to take a second look at the API for
> IHeaderResponse and I think I've figured out a workaround. If I use
> renderJavascript() it doesn't include the js file from wicket, then I can
> just manually write my own onload handler which utilizes the output from
> the renderJavascript() call. I'm fairly confident that should cover me
> for almost any situation that comes up. It may not always be the cleanest
> code, but it's better than wasting hours getting oc4j (assuming it's
> oc4j's fault) to behave.
>
> Thanks for the suggestion, it may have indirectly solved my problem.
>
> Joel
>
>
>
> Alex Objelean wrote:
>>
>> I've got the same problem. A quick fix for you can be give-up using
>> home-grown compression filter or instead of using IHeaderContributor to
>> include dynamic Javascript:
>>
>> [code]
>> public void renderHead(final IHeaderResponse response) {
>> response.renderJavascriptReference(new JavascriptResourceReference(
>> WicketApplication.class, "ref/javascriptFile.js"));
>> }
>> [/code]
>>
>> include the JS this way:
>>
>> [code]
>> add(new JavaScriptReference("js.markupId",
>> WicketApplication.class, "ref/javascriptFile.js"));
>> [/code]
>>
>> I do not understand the difference between these two methods of adding
>> JavascriptReference object (maybe this is related to gzip compression
>> used by wicket), but I've noticed that this makes the difference.
>>
>> PS: I use for compression the
>> http://sourceforge.net/project/showfiles.php?group_id=195642 Resource
>> Accelerate project. I find it very useful.
>>
>>
>> hillj2 wrote:
>>>
>>> I'm using IHeaderContributor to include dynamic Javascript; however,
>>> wicket-event.js is returning to the browser as unreadable garbage. I
>>> think it MAY have something to do with compression. Our app uses a
>>> home-grown compression filter, and I also read today that wicket uses
>>> default compression too. I tried disabling one or the other or both but
>>> this didn't work UNLESS I was using NetTool, which basically acts as a
>>> request intercept that spits out the request/response headers. I
>>> wouldn't expect NetTool to modify the request/response at all, but for
>>> some reason if I have at least one of the compression filters disabled
>>> AND go through NetTool wicket-event.js returns fine.
>>>
>>> I also get this in my log output when the js file fails to return
>>> properly:
>>>
>>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>>> (locateByResourceFinder:197) - Attempting to locate resource
>>> 'org/apache/wicket/markup/html/wicket-event.js' on path [folders = [],
>>> webapppaths: []]
>>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>>> (locateByClassLoader:166) - Attempting to locate resource
>>> 'org/apache/wicket/markup/html/wicket-event.js' using classloader
>>> mcir.root:0.0.0
>>> DEBUG 2007-07-27 10:54:19,156 resource.UrlResourceStream (<init>:92) -
>>> cannot convert url:
>>> code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-Beta-20070606.jar!/org/apache/wicket/markup/html/wicket-event.js
>>> to file (URI scheme is not "file"), falling back to the inputstream for
>>> polling
>>>
>>>
>>> What makes it even more odd is I've used IHeaderContributor in another,
>>> far simpler app before and it's worked fine.
>>>
>>> Thanks.
>>>
>>> Joel
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12028941
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by hillj2 <Hi...@michigan.gov>.
Well I have the compression filter turned off now, so that shouldn't be the
problem. And I'm not trying to dynamically include a js file, but create
dynamic js which runs onload:
response.renderOnLoadJavascript("some js code");
However, your suggestion inspired me to take a second look at the API for
IHeaderResponse and I think I've figured out a workaround. If I use
renderJavascript() it doesn't include the js file from wicket, then I can
just manually write my own onload handler which utilizes the output from the
renderJavascript() call. I'm fairly confident that should cover me for
almost any situation that comes up. It may not always be the cleanest code,
but it's better than wasting hours getting oc4j (assuming it's oc4j's fault)
to behave.
Thanks for the suggestion, it may have indirectly solved my problem.
Joel
Alex Objelean wrote:
>
> I've got the same problem. A quick fix for you can be give-up using
> home-grown compression filter or instead of using IHeaderContributor to
> include dynamic Javascript:
>
> [code]
> public void renderHead(final IHeaderResponse response) {
> response.renderJavascriptReference(new JavascriptResourceReference(
> WicketApplication.class, "ref/javascriptFile.js"));
> }
> [/code]
>
> include the JS this way:
>
> [code]
> add(new JavaScriptReference("js.markupId",
> WicketApplication.class, "ref/javascriptFile.js"));
> [/code]
>
> I do not understand the difference between these two methods of adding
> JavascriptReference object (maybe this is related to gzip compression used
> by wicket), but I've noticed that this makes the difference.
>
> PS: I use for compression the
> http://sourceforge.net/project/showfiles.php?group_id=195642 Resource
> Accelerate project. I find it very useful.
>
>
> hillj2 wrote:
>>
>> I'm using IHeaderContributor to include dynamic Javascript; however,
>> wicket-event.js is returning to the browser as unreadable garbage. I
>> think it MAY have something to do with compression. Our app uses a
>> home-grown compression filter, and I also read today that wicket uses
>> default compression too. I tried disabling one or the other or both but
>> this didn't work UNLESS I was using NetTool, which basically acts as a
>> request intercept that spits out the request/response headers. I
>> wouldn't expect NetTool to modify the request/response at all, but for
>> some reason if I have at least one of the compression filters disabled
>> AND go through NetTool wicket-event.js returns fine.
>>
>> I also get this in my log output when the js file fails to return
>> properly:
>>
>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>> (locateByResourceFinder:197) - Attempting to locate resource
>> 'org/apache/wicket/markup/html/wicket-event.js' on path [folders = [],
>> webapppaths: []]
>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>> (locateByClassLoader:166) - Attempting to locate resource
>> 'org/apache/wicket/markup/html/wicket-event.js' using classloader
>> mcir.root:0.0.0
>> DEBUG 2007-07-27 10:54:19,156 resource.UrlResourceStream (<init>:92) -
>> cannot convert url:
>> code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-Beta-20070606.jar!/org/apache/wicket/markup/html/wicket-event.js
>> to file (URI scheme is not "file"), falling back to the inputstream for
>> polling
>>
>>
>> What makes it even more odd is I've used IHeaderContributor in another,
>> far simpler app before and it's worked fine.
>>
>> Thanks.
>>
>> Joel
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12018207
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by Alex Objelean <al...@isdc.ro>.
I've got the same problem. A quick fix for you can be give-up using
home-grown compression filter or instead of using IHeaderContributor to
include dynamic Javascript:
[code]
public void renderHead(final IHeaderResponse response) {
response.renderJavascriptReference(new JavascriptResourceReference(
WicketApplication.class, "ref/javascriptFile.js"));
}
[/code]
include the JS this way:
[code]
add(new JavaScriptReference("js.markupId",
WicketApplication.class, "ref/javascriptFile.js"));
[/code]
I do not understand the difference between these two methods of adding
JavascriptReference object (maybe this is related to gzip compression used
by wicket), but I've noticed that this makes the difference.
PS: I use for compression the
http://sourceforge.net/project/showfiles.php?group_id=195642 Resource
Accelerate project. I find it very useful.
hillj2 wrote:
>
> I'm using IHeaderContributor to include dynamic Javascript; however,
> wicket-event.js is returning to the browser as unreadable garbage. I
> think it MAY have something to do with compression. Our app uses a
> home-grown compression filter, and I also read today that wicket uses
> default compression too. I tried disabling one or the other or both but
> this didn't work UNLESS I was using NetTool, which basically acts as a
> request intercept that spits out the request/response headers. I
> wouldn't expect NetTool to modify the request/response at all, but for
> some reason if I have at least one of the compression filters disabled
> AND go through NetTool wicket-event.js returns fine.
>
> I also get this in my log output when the js file fails to return
> properly:
>
> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
> (locateByResourceFinder:197) - Attempting to locate resource
> 'org/apache/wicket/markup/html/wicket-event.js' on path [folders = [],
> webapppaths: []]
> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
> (locateByClassLoader:166) - Attempting to locate resource
> 'org/apache/wicket/markup/html/wicket-event.js' using classloader
> mcir.root:0.0.0
> DEBUG 2007-07-27 10:54:19,156 resource.UrlResourceStream (<init>:92) -
> cannot convert url:
> code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-Beta-20070606.jar!/org/apache/wicket/markup/html/wicket-event.js
> to file (URI scheme is not "file"), falling back to the inputstream for
> polling
>
>
> What makes it even more odd is I've used IHeaderContributor in another,
> far simpler app before and it's worked fine.
>
> Thanks.
>
> Joel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12017032
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-event.js returning unreadable
Posted by Matej Knopp <ma...@gmail.com>.
Probably your compression filter doesn't check if the content is
already compressed. But it should, because we set the correct headers.
-Matej
On 7/27/07, Joel Hill <Hi...@michigan.gov> wrote:
> I'm using IHeaderContributor to include dynamic Javascript; however,
> wicket-event.js is returning to the browser as unreadable garbage. I
> think it MAY have something to do with compression. Our app uses a
> home-grown compression filter, and I also read today that wicket uses
> default compression too. I tried disabling one or the other or both but
> this didn't work UNLESS I was using NetTool, which basically acts as a
> request intercept that spits out the request/response headers. I
> wouldn't expect NetTool to modify the request/response at all, but for
> some reason if I have at least one of the compression filters disabled
> AND go through NetTool wicket-event.js returns fine.
>
> I also get this in my log output when the js file fails to return
> properly:
>
> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
> (locateByResourceFinder:197) - Attempting to locate resource
> 'org/apache/wicket/markup/html/wicket-event.js' on path [folders = [],
> webapppaths: []]
> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
> (locateByClassLoader:166) - Attempting to locate resource
> 'org/apache/wicket/markup/html/wicket-event.js' using classloader
> mcir.root:0.0.0
> DEBUG 2007-07-27 10:54:19,156 resource.UrlResourceStream (<init>:92) -
> cannot convert url:
> code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-Beta-20070606.jar!/org/apache/wicket/markup/html/wicket-event.js
> to file (URI scheme is not "file"), falling back to the inputstream for
> polling
>
>
> What makes it even more odd is I've used IHeaderContributor in another,
> far simpler app before and it's worked fine.
>
> Thanks.
>
> Joel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org