Re: Access denied to (static) package resource
Thanks that's handy and explains it well. The resource is part of the Wicket internals though and not something of my making. On 6 Sep 2013, at 16:48, Andrea Del Bene wrote: you should add the file type you want to load to the set of allowed extensions. Take a look here: http://wicketguide.comsysto.com/guide/chapter19.html#chapter19_4 I'm getting the exception below occurring occasionally and I can't figure out why. I have read the javadoc for IPackageResourceGuard but still not really enlightened as to why this is occurring. Under what circumstances will access be denied? In Application init(): getJavaScriptLibrarySettings().setJQueryReference(new DynamicJQueryResourceReference()); 2013-09-06 14:59:47,417 [jk-listener(2)] DEBUG o.a.w.r.m.CompoundRequestMapper - One compatible mapper found for URL 'wicket/resource/org.apache.wicket.resource.DynamicJQueryResourceReference/jquery/jquery-2.0.2.min.map' -> 'Mapper: org.apache.wicket.core.request.mapper.ResourceReferenceMapper; Score: 1' 2013-09-06 14:59:47,418 [jk-listener(2)] ERROR o.a.w.DefaultExceptionMapper - Unexpected error occurred org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: Access denied to (static) package resource org/apache/wicket/resource/jquery/jquery-2.0.2.min.map. See IPackageResourceGuard at org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:460) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.resource.PackageResource.getResourceStream(PackageResource.java:405) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.resource.PackageResource.newResourceResponse(PackageResource.java:267) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:498) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:75) ~[wicket-core-6.10.0.jar:6.10.0] - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Access denied to (static) package resource
I'm getting the exception below occurring occasionally and I can't figure out why. I have read the javadoc for IPackageResourceGuard but still not really enlightened as to why this is occurring. Under what circumstances will access be denied? In Application init(): getJavaScriptLibrarySettings().setJQueryReference(new DynamicJQueryResourceReference()); 2013-09-06 14:59:47,417 [jk-listener(2)] DEBUG o.a.w.r.m.CompoundRequestMapper - One compatible mapper found for URL 'wicket/resource/org.apache.wicket.resource.DynamicJQueryResourceReference/jquery/jquery-2.0.2.min.map' -> 'Mapper: org.apache.wicket.core.request.mapper.ResourceReferenceMapper; Score: 1' 2013-09-06 14:59:47,418 [jk-listener(2)] ERROR o.a.w.DefaultExceptionMapper - Unexpected error occurred org.apache.wicket.request.resource.PackageResource$PackageResourceBlockedException: Access denied to (static) package resource org/apache/wicket/resource/jquery/jquery-2.0.2.min.map. See IPackageResourceGuard at org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:460) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.resource.PackageResource.getResourceStream(PackageResource.java:405) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.resource.PackageResource.newResourceResponse(PackageResource.java:267) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:498) ~[wicket-core-6.10.0.jar:6.10.0] at org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:75) ~[wicket-core-6.10.0.jar:6.10.0] - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WebSockets / Atmosphere with Glassfish 4.0?
Thanks Martin, that saves me some pain. I'd be all for a bit of extra Wicket configuration rather than hope the GF team acts on your request. On 30 Aug 2013, at 10:46, Martin Grigorov wrote: Hi, I've tried to make a module for GF 3 for Native WebSockets when Native WS module has been introduced - https://github.com/apache/wicket/tree/sandbox/wicket-native-websocket-glassfish But it didn't work well because of: bugs in GF 3, lack of demo apps, lack of interest. Recently I've added JSR356 based implementation to Wicket 7 - https://github.com/apache/wicket/tree/master/wicket-experimental/wicket-native-websocket/wicket-native-websocket-javax But again this doesn't work on GF 4 :-/ due to https://java.net/jira/browse/WEBSOCKET_SPEC-181. The impl works with Tomcat 8, and Tomcat 7 (next release will have the JSR based impl backported). This can be improved by moving the WebSocket Endpoint creation logic to a ServletContextListener instead of a Filter but this will require additional setup steps that I'd like to avoid. Has anyone managed to use Wicket + native WebSockets or Atmosphere on Glassfish 4.0? Neither of the current modules work out of the box on Glassfish 4.0, just wondering if anyone has had any success with this combination or can give me any time saving pointers. -Phill --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
WebSockets / Atmosphere with Glassfish 4.0?
Has anyone managed to use Wicket + native WebSockets or Atmosphere on Glassfish 4.0? Neither of the current modules work out of the box on Glassfish 4.0, just wondering if anyone has had any success with this combination or can give me any time saving pointers. -Phill - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
CDI WELD-000070 Simple bean cannot be a non-static inner class
I'm trying to use wicket-cdi with Glassfish 4.0 and get the following exceptions. Should wicket-cdi work with soon-to-be-released Java EE 7 / CDI 1.1 ? 2013-06-10 17:12:34,351 [http-listener-2(2)] DEBUG o.apache.wicket.MarkupContainer - Add markupHighlight to [Page class = org.apache.wicket.markup.html.pages.ExceptionErrorPage, id = 3, render count = 0] 2013-06-10 17:12:34,354 [http-listener-2(2)] ERROR o.a.w.DefaultExceptionMapper - An error occurred while handling a previous error: WELD-70 Simple bean [EnhancedAnnotatedTypeImpl] class org.apache.wicket.markup.html.pages.ExceptionErrorPage$1 cannot be a non-static inner class org.jboss.weld.exceptions.IllegalArgumentException: WELD-70 Simple bean [EnhancedAnnotatedTypeImpl] class org.apache.wicket.markup.html.pages.ExceptionErrorPage$1 cannot be a non-static inner class at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:82) ~[weld-osgi-bundle.jar:20130513-1450] at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:68) ~[weld-osgi-bundle.jar:20130513-1450] at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1039) ~[weld-osgi-bundle.jar:20130513-1450] at org.jboss.weld.util.ForwardingBeanManager.createInjectionTarget(ForwardingBeanManager.java:201) ~[weld-osgi-bundle.jar:20130513-1450] at org.apache.wicket.cdi.NonContextual.(NonContextual.java:118) ~[wicket-cdi-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.cdi.NonContextual.of(NonContextual.java:84) ~[wicket-cdi-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.cdi.NonContextualManager.inject(NonContextualManager.java:54) ~[wicket-cdi-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.cdi.AbstractInjector.inject(AbstractInjector.java:43) ~[wicket-cdi-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.cdi.ComponentInjector.onInstantiation(ComponentInjector.java:43) ~[wicket-cdi-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:38) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.application.ComponentInstantiationListenerCollection$1.notify(ComponentInstantiationListenerCollection.java:34) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.util.listener.ListenerCollection.notify(ListenerCollection.java:80) ~[wicket-util-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.application.ComponentInstantiationListenerCollection.onInstantiation(ComponentInstantiationListenerCollection.java:33) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.Component.(Component.java:683) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.MarkupContainer.(MarkupContainer.java:121) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.markup.html.WebMarkupContainer.(WebMarkupContainer.java:52) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.markup.html.link.AbstractLink.(AbstractLink.java:57) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.markup.html.link.AbstractLink.(AbstractLink.java:44) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.markup.html.link.Link.(Link.java:105) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.markup.html.pages.ExceptionErrorPage$1.(ExceptionErrorPage.java:97) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.markup.html.pages.ExceptionErrorPage.(ExceptionErrorPage.java:96) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.DefaultExceptionMapper.internalMap(DefaultExceptionMapper.java:128) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.DefaultExceptionMapper.map(DefaultExceptionMapper.java:62) ~[wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.request.cycle.RequestCycle.handleException(RequestCycle.java:352) [wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:229) [wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:289) [wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(WicketFilter.java:259) [wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:201) [wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) [wicket-core-6.9.0-SNAPSHOT.jar:6.9.0-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) [web-core.jar:na] at org.apache.cat
Re: Expired AjaxLink on bookmarkable page not maintaining request parameters
As it's the last parameter in the url I think I'll recover it from the Request Url segments. On 10/ott/2012, at 13:51, Ernesto Reinaldo Barreiro wrote: > Maybe keep a cookie and redirect to the mounted page (with right > parameters) after session expires? > > On Wed, Oct 10, 2012 at 3:52 AM, Phill wrote: > >> Do you have any suggestions for gracefully recovering from this? >> Without access to the named parameter I cannot construct the model for the >> page and I would like recreate the page on the original mount point. >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Expired AjaxLink on bookmarkable page not maintaining request parameters
Do you have any suggestions for gracefully recovering from this?
Without access to the named parameter I cannot construct the model for the page
and I would like recreate the page on the original mount point.
On 10/ott/2012, at 10:20, Martin Grigorov wrote:
> Hi,
>
> This is the behavior since https://issues.apache.org/jira/browse/WICKET-4594
> As the ticket explains the problem was that *all* parameters for the
> Ajax request were assumed to be the PageParameters for the freshly
> created page. And this causes other problems ... :-/
>
> On Wed, Oct 10, 2012 at 11:11 AM, Phill wrote:
>> Wicket 6.1.1 - I'm mounting a bookmarkable page in my Application with a
>> named parameter:
>>
>> mountPage("/user/${userId}", UserPage.class);
>>
>> If I click an expired (session timeout) AjaxLink on the page /user/ABC it is
>> detected and handled by the RequestHandler but the named parameter is not
>> passed to the recreated page, redirecting to /user/?1 and not /user/ABC
>>
>> 2012-10-10 08:50:30,924 [http-thread-pool-8009(3)] DEBUG
>> o.a.wicket.core.request.handler.ListenerInterfaceRequestHandler - A
>> ListenerInterface '[RequestListenerInterface name=IBehaviorListener,
>> method=public abstract void
>> org.apache.wicket.behavior.IBehaviorListener.onRequest()]' assigned to
>> 'content:addCommentLink' is executed on an expired stateful page. Scheduling
>> re-create of the page and ignoring the listener interface…
>>
>> Is this the expected behaviour or a bug?
>> -Phill
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Expired AjaxLink on bookmarkable page not maintaining request parameters
Wicket 6.1.1 - I'm mounting a bookmarkable page in my Application with a named
parameter:
mountPage("/user/${userId}", UserPage.class);
If I click an expired (session timeout) AjaxLink on the page /user/ABC it is
detected and handled by the RequestHandler but the named parameter is not
passed to the recreated page, redirecting to /user/?1 and not /user/ABC
2012-10-10 08:50:30,924 [http-thread-pool-8009(3)] DEBUG
o.a.wicket.core.request.handler.ListenerInterfaceRequestHandler - A
ListenerInterface '[RequestListenerInterface name=IBehaviorListener,
method=public abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]' assigned to
'content:addCommentLink' is executed on an expired stateful page. Scheduling
re-create of the page and ignoring the listener interface…
Is this the expected behaviour or a bug?
-Phill
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Changing markup location in 6.0
I've got a 1.5.x app which I'm converting to 6.0-beta3 and I keep my markup
separate and under "WEB-INF/html".
With 1.5.x I use the following in my Application class:
IResourceSettings resourceSettings = getResourceSettings();
resourceSettings.addResourceFolder("WEB-INF/html/");
I can't seem to find an equivalent in 6.0 that allows me to load from this
location, I've tried the 3 IResourceFinders - ClassPathResourceFinder, Path,
WebApplicationPath as follows but I can't get any of them to work.
IResourceSettings resourceSettings = getResourceSettings();
resourceSettings.getResourceFinders().add();
Is there any way to do this in 6.0?
-Phill
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-cdi NotSerializableException for injected SLSB proxy
https://github.com/42Lines/wicket-cdi/issues/14
On 24/nov/2011, at 17:19, Igor Vaynberg wrote:
> btw, feel free to open an issue in wicket-cdi
>
> -igor
>
> On Thu, Nov 24, 2011 at 4:03 AM, Phill wrote:
>> On further investigation it doesn't seem to be a weld/glassfish bug as as
>> far as I can tell there is no requirement for a Stateless EJB proxy to be
>> serializable.
>> The issue was raised here where a patch to seam-wicket was proposed:
>> https://issues.jboss.org/browse/SEAMWICKET-41
>> Any chance of a similar workaround for wicket-cdi?
>>
>> Interestingly if I inject the @Stateless EJB into an @ApplicationScoped bean
>> and then inject the application scoped bean into my page there are no
>> serialization issues, suggesting that in this case the proxy for the SLSB is
>> serializable.
>> -Phill
>>
>>
>> On 16/nov/2011, at 17:24, Igor Vaynberg wrote:
>>
>>> looks like a weld/glassfish bug, especially since other kinds of proxies
>>> (even for application-scoped objects) are serializable.
>>>
>>> -igor
>>>
>>> On Wed, Nov 16, 2011 at 12:52 AM, Phill wrote:
>>>
>>>> I'm using the wicket-cdi module (https://github.com/42Lines/wicket-cdi)
>>>> to inject an SLSB with Glassfish 3.1.1
>>>>
>>>> MyWebApplication.init()
>>>>
>>>> BeanManager manager = (BeanManager) ic.lookup("java:comp/BeanManager");
>>>> new CdiConfiguration(manager)
>>>> .setPropagation(ConversationPropagation.NONBOOKMARKABLE)
>>>> .configure(this);
>>>>
>>>> public class DashboardPage extends AuthorisedBasePage {
>>>> @Inject
>>>> private AccountingService accountingService;
>>>> …
>>>> }
>>>>
>>>> Injection is working fine and I can use the session bean but Wicket is
>>>> unable to serialize the proxy.
>>>> According to my research previous issues with the Weld proxy not being
>>>> serializable should have been resolved in the version that shipped with GF
>>>> 3.1.
>>>> I've also tried the latest GF 3.1.2 promoted build which uses Weld 1.1.3
>>>> and I get the same problem.
>>>>
>>>> I'm not really sure if this is a Wicket issue or whether I should be
>>>> taking it up with the Weld team.. any pointers appreciated.
>>>>
>>>>
>>>> 2011-11-16 09:05:17,201 [http-thread-pool-8181(4)] ERROR
>>>> org.apache.wicket.serialize.java.JavaSerializer - Error serializing object
>>>> class uk.co.leadseeker.webapp.user.DashboardPage [object=[Page class =
>>>> uk.co.leadseeker.webapp.user.DashboardPage, id = 3, render count = 1]]
>>>> java.io.NotSerializableException
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket-cdi NotSerializableException for injected SLSB proxy
On further investigation it doesn't seem to be a weld/glassfish bug as as far
as I can tell there is no requirement for a Stateless EJB proxy to be
serializable.
The issue was raised here where a patch to seam-wicket was proposed:
https://issues.jboss.org/browse/SEAMWICKET-41
Any chance of a similar workaround for wicket-cdi?
Interestingly if I inject the @Stateless EJB into an @ApplicationScoped bean
and then inject the application scoped bean into my page there are no
serialization issues, suggesting that in this case the proxy for the SLSB is
serializable.
-Phill
On 16/nov/2011, at 17:24, Igor Vaynberg wrote:
> looks like a weld/glassfish bug, especially since other kinds of proxies
> (even for application-scoped objects) are serializable.
>
> -igor
>
> On Wed, Nov 16, 2011 at 12:52 AM, Phill wrote:
>
>> I'm using the wicket-cdi module (https://github.com/42Lines/wicket-cdi)
>> to inject an SLSB with Glassfish 3.1.1
>>
>> MyWebApplication.init()
>>
>> BeanManager manager = (BeanManager) ic.lookup("java:comp/BeanManager");
>> new CdiConfiguration(manager)
>> .setPropagation(ConversationPropagation.NONBOOKMARKABLE)
>> .configure(this);
>>
>> public class DashboardPage extends AuthorisedBasePage {
>> @Inject
>> private AccountingService accountingService;
>> …
>> }
>>
>> Injection is working fine and I can use the session bean but Wicket is
>> unable to serialize the proxy.
>> According to my research previous issues with the Weld proxy not being
>> serializable should have been resolved in the version that shipped with GF
>> 3.1.
>> I've also tried the latest GF 3.1.2 promoted build which uses Weld 1.1.3
>> and I get the same problem.
>>
>> I'm not really sure if this is a Wicket issue or whether I should be
>> taking it up with the Weld team.. any pointers appreciated.
>>
>>
>> 2011-11-16 09:05:17,201 [http-thread-pool-8181(4)] ERROR
>> org.apache.wicket.serialize.java.JavaSerializer - Error serializing object
>> class uk.co.leadseeker.webapp.user.DashboardPage [object=[Page class =
>> uk.co.leadseeker.webapp.user.DashboardPage, id = 3, render count = 1]]
>> java.io.NotSerializableException
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
wicket-cdi NotSerializableException for injected SLSB proxy
ltProtocolFilter.java:225) [grizzly-http.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) [grizzly-http.jar:1.9.36] at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.ContextTask.run(ContextTask.java:71) [grizzly-framework.jar:1.9.36] at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) [grizzly-utils.jar:1.9.36] at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) [grizzly-utils.jar:1.9.36] at java.lang.Thread.run(Thread.java:680) [na:1.6.0_29] 2011-11-16 09:05:17,205 [http-thread-pool-8181(4)] WARN org.apache.wicket.pageStore.DefaultPageStore - Page [Page class = uk.co.leadseeker.webapp.user.DashboardPage, id = 3, render count = 1] cannot be serialized. See previous logs for possible reasons. Phill - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CryptoMapper - Error decoding text
https://issues.apache.org/jira/browse/WICKET-4222 On 12/nov/2011, at 23:33, Igor Vaynberg wrote: > go ahead and create a quickstart and stick it into a jira. > > thanks, > -igor > > On Sat, Nov 12, 2011 at 11:30 AM, Phill wrote: >> I have now, same problem: >> >> INFO - WebApplication - [wicket.cryptest] Started Wicket >> version 1.5.3 in DEVELOPMENT mode >> >> *** WARNING: Wicket is running in DEVELOPMENT mode. *** >> *** ^^^*** >> *** Do NOT deploy to your live server(s) without changing this. *** >> *** See Application#getConfigurationType() for more information. *** >> >> 2011-11-12 20:27:59.244:INFO:oejs.AbstractConnector:Started >> SelectChannelConnector@0.0.0.0:8080 STARTING >> 2011-11-12 20:27:59.435:INFO:oejs.AbstractConnector:Started >> SslSocketConnector@0.0.0.0:8443 STARTING >> [INFO] Started Jetty Server >> ERROR - AbstractCrypt - Error decoding text: logo.png >> java.lang.RuntimeException: Unable to decrypt the text '??(?x' >>at >> org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:150) >>at >> org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe(AbstractCrypt.java:66) >>at >> org.apache.wicket.request.mapper.CryptoMapper.decryptUrl(CryptoMapper.java:159) >>at >> org.apache.wicket.request.mapper.CryptoMapper.mapRequest(CryptoMapper.java:102) >> >> Phill - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CryptoMapper - Error decoding text
I have now, same problem:
INFO - WebApplication - [wicket.cryptest] Started Wicket version
1.5.3 in DEVELOPMENT mode
*** WARNING: Wicket is running in DEVELOPMENT mode. ***
*** ^^^***
*** Do NOT deploy to your live server(s) without changing this. ***
*** See Application#getConfigurationType() for more information. ***
2011-11-12 20:27:59.244:INFO:oejs.AbstractConnector:Started
SelectChannelConnector@0.0.0.0:8080 STARTING
2011-11-12 20:27:59.435:INFO:oejs.AbstractConnector:Started
SslSocketConnector@0.0.0.0:8443 STARTING
[INFO] Started Jetty Server
ERROR - AbstractCrypt - Error decoding text: logo.png
java.lang.RuntimeException: Unable to decrypt the text '??(?x'
at
org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:150)
at
org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe(AbstractCrypt.java:66)
at
org.apache.wicket.request.mapper.CryptoMapper.decryptUrl(CryptoMapper.java:159)
at
org.apache.wicket.request.mapper.CryptoMapper.mapRequest(CryptoMapper.java:102)
Phill
On 12/nov/2011, at 19:33, Igor Vaynberg wrote:
> have you tried with 1.5.3?
>
> -gior
>
> On Sat, Nov 12, 2011 at 10:27 AM, Phill wrote:
>> Thanks, I had put setRootRequestMapper(..) first after reading
>> https://issues.apache.org/jira/browse/WICKET-4139
>> However putting it last does not seem to solve the problem, I can replicate
>> the error with a pristine 1.5.2 quickstart and just changing the init() to:
>>
>> public void init() {
>>super.init();
>>getSecuritySettings().setCryptFactory(new
>> KeyInSessionSunJceCryptFactory());
>>setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
>> }
>>
>> The links in the standard quickstart HomePage.html markup cause the
>> exceptions.
>> Phill
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: CryptoMapper - Error decoding text
Thanks, I had put setRootRequestMapper(..) first after reading
https://issues.apache.org/jira/browse/WICKET-4139
However putting it last does not seem to solve the problem, I can replicate the
error with a pristine 1.5.2 quickstart and just changing the init() to:
public void init() {
super.init();
getSecuritySettings().setCryptFactory(new KeyInSessionSunJceCryptFactory());
setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
}
The links in the standard quickstart HomePage.html markup cause the exceptions.
Phill
On 12/nov/2011, at 18:39, Igor Vaynberg wrote:
> this:
>
> setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
>
> should be the last thing you do in your application#init()
>
> -igor
>
> On Sat, Nov 12, 2011 at 6:45 AM, Phill wrote:
>> Hi,
>> I'm migrating a Wicket 1.4 app that uses CryptedUrlWebRequestCodingStrategy
>> to 1.5.2 and I'm having some issues:
>>
>> In my Application init() before I mount any pages I've got:
>> getSecuritySettings().setCryptFactory(new KeyInSessionSunJceCryptFactory());
>> setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
>>
>> Any non-wicket URLs in my markup, for example image tags > src="/images/myimg.jpg" …./> and also any references added in
>> WebPage.renderHead() produce the exception below. The page displays fine
>> including correctly linked images and stylesheets, but the exception is
>> thrown.
>>
>> @Override
>> public void renderHead(IHeaderResponse response) {
>>super.renderHead(response);
>>response.renderCSSReference("css/style.css");
>> }
>>
>>
>> ERROR - AbstractCrypt - Error decoding text: css
>> java.lang.RuntimeException: Unable to decrypt the text 'r?'
>>at
>> org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:150)
>>at
>> org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe(AbstractCrypt.java:66)
>>at
>> org.apache.wicket.request.mapper.CryptoMapper.decryptUrl(CryptoMapper.java:159)
>>at
>> org.apache.wicket.request.mapper.CryptoMapper.mapRequest(CryptoMapper.java:102)
>>at
>> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:181)
>>at
>> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:206)
>>at
>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
>>at
>> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
>>at
>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
>>at
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1326)
>> ..snip
>> Caused by: javax.crypto.IllegalBlockSizeException: Input length must be
>> multiple of 8 when decrypting with padded cipher
>>at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>>at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
>>at com.sun.crypto.provider.SunJCE_ab.b(DashoA13*..)
>>at
>> com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA13*..)
>>at javax.crypto.Cipher.doFinal(DashoA13*..)
>>at org.apache.wicket.util.crypt.SunJceCrypt.crypt(SunJceCrypt.java:94)
>>at
>> org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:146)
>>... 32 more
>> ERROR - CryptoMapper - Error decrypting URL
>> java.lang.IllegalArgumentException: Argument 'url' may not be null.
>>at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
>>at org.apache.wicket.request.Url.parse(Url.java:127)
>>at
>> org.apache.wicket.request.mapper.CryptoMapper.decryptUrl(CryptoMapper.java:160)
>>at
>> org.apache.wicket.request.mapper.CryptoMapper.mapRequest(CryptoMapper.java:102)
>>at
>> org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:181)
>>at
>> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:206)
>>at
>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
>>at
>> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
>>at
>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
>> ..snip
>>
>> How can I avoid thes
CryptoMapper - Error decoding text
Hi,
I'm migrating a Wicket 1.4 app that uses CryptedUrlWebRequestCodingStrategy to
1.5.2 and I'm having some issues:
In my Application init() before I mount any pages I've got:
getSecuritySettings().setCryptFactory(new KeyInSessionSunJceCryptFactory());
setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
Any non-wicket URLs in my markup, for example image tags and also any references added in
WebPage.renderHead() produce the exception below. The page displays fine
including correctly linked images and stylesheets, but the exception is thrown.
@Override
public void renderHead(IHeaderResponse response) {
super.renderHead(response);
response.renderCSSReference("css/style.css");
}
ERROR - AbstractCrypt - Error decoding text: css
java.lang.RuntimeException: Unable to decrypt the text 'r?'
at
org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:150)
at
org.apache.wicket.util.crypt.AbstractCrypt.decryptUrlSafe(AbstractCrypt.java:66)
at
org.apache.wicket.request.mapper.CryptoMapper.decryptUrl(CryptoMapper.java:159)
at
org.apache.wicket.request.mapper.CryptoMapper.mapRequest(CryptoMapper.java:102)
at
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:181)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:206)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1326)
..snip
Caused by: javax.crypto.IllegalBlockSizeException: Input length must be
multiple of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_ab.b(DashoA13*..)
at
com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at org.apache.wicket.util.crypt.SunJceCrypt.crypt(SunJceCrypt.java:94)
at
org.apache.wicket.util.crypt.AbstractCrypt.decryptByteArray(AbstractCrypt.java:146)
... 32 more
ERROR - CryptoMapper - Error decrypting URL
java.lang.IllegalArgumentException: Argument 'url' may not be null.
at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
at org.apache.wicket.request.Url.parse(Url.java:127)
at
org.apache.wicket.request.mapper.CryptoMapper.decryptUrl(CryptoMapper.java:160)
at
org.apache.wicket.request.mapper.CryptoMapper.mapRequest(CryptoMapper.java:102)
at
org.apache.wicket.request.cycle.RequestCycle.resolveRequestHandler(RequestCycle.java:181)
at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:206)
at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
at
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
..snip
How can I avoid these errors?
Thanks
Phill
---
Lead Seeker - Lead Generation Done Right
http://www.leadseeker.co.uk
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: @RequireHttps start session before redirect to secure page
thanks I'll try that, it is possible that they go straight to the login page but unlikely so I should be ok. On 29/mar/2011, at 18.31, Igor Vaynberg wrote: > simply call session.bind() in requestcycle.onendrequest() which will > make sure the session is bound on every request. > > you can still have a problem if the login page is the first page hit > by the user. can that be the case in your application? > > -igor > > > On Tue, Mar 29, 2011 at 5:38 AM, Phill wrote: >> I'm running into this problem as described in the javadocs for >> HttpsRequestCycleProcessor: >> >> "Notes: According to servlet spec a cookie created on an https request is >> marked as secure, such cookies are not available for http requests. What >> this means is that a session started over https will not be propagated to >> further http calls because JSESSIONID cookie will be marked as secure and >> not available to http requests. This entails that unless a session is >> created and bound on http prior to using an https request any wicket pages >> or session values stored in the https session will not be available to >> further http requests. If your application requires a http->https->http >> interactions (such as the case where only a login page and my account pages >> are secure) you must make sure a session is created and stored in the http >> request prior to the first http->https redirect." >> >> When my users start a session via the sign-in page protected by >> @RequireHttps they are then redirected to a non-ssl but >> authorisation-protected page, but as there is no insecure session at that >> point they are bounced back to the sign-in page again. >> >> I would really appreciate some suggestions as to how others users deal with >> this issue i.e. how could I ensure that a session is created and stored in >> the http request prior to the first http->https redirect? >> >> I thought about having a non-ssl protected sign-in page which has an >> immediate javascript redirect to the ssl version but it doesn't seem very >> elegant. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
@RequireHttps start session before redirect to secure page
I'm running into this problem as described in the javadocs for HttpsRequestCycleProcessor: "Notes: According to servlet spec a cookie created on an https request is marked as secure, such cookies are not available for http requests. What this means is that a session started over https will not be propagated to further http calls because JSESSIONID cookie will be marked as secure and not available to http requests. This entails that unless a session is created and bound on http prior to using an https request any wicket pages or session values stored in the https session will not be available to further http requests. If your application requires a http->https->http interactions (such as the case where only a login page and my account pages are secure) you must make sure a session is created and stored in the http request prior to the first http->https redirect." When my users start a session via the sign-in page protected by @RequireHttps they are then redirected to a non-ssl but authorisation-protected page, but as there is no insecure session at that point they are bounced back to the sign-in page again. I would really appreciate some suggestions as to how others users deal with this issue i.e. how could I ensure that a session is created and stored in the http request prior to the first http->https redirect? I thought about having a non-ssl protected sign-in page which has an immediate javascript redirect to the ssl version but it doesn't seem very elegant. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Mount a page to root path in wicket 1.5
Martin Grigorov-4 wrote:
>
> See WICKET-3126. I attached a patch and unit tests.
> Now the Url is stable - always "/".
>
> The problem comes when the user application wants to re-map to different
> class than application#getHomePage - MountedMapper("/", ...) believes that
> *all* requests to bookmarkable pages (/wicket/bookmarkable/com.xyz.MyPage)
> are targeted to "/" and the rest are indexed parameters...
> So it is not quite true what I said in my previous mail.
>
With 1.5-M3 doing mountPage("/", getHomePage()) seems to mess up the paths
to my CSS files, both in the homepage and elsewhere. I'm using a behaviour
to add the links relative to context root:
public void renderHead(IHeaderResponse response) {
response.renderCSSReference("css/main.css", "screen projection");
}
With home page mounted on "/" gives this link which is incorrect and doesn't
take into account the context root.
With the default home page mount "/wicket/bookmarkable/com.xyz.MyHomePage" the link is as follows and
works fine.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Mount-a-page-to-root-path-in-wicket-1-5-tp3003270p3165707.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
