Re: Accessing Wicket Application from custom servlet
That seems to provide a solutino for WicketSession access, but what about access to the Application instance? On Tue, Aug 4, 2009 at 1:51 PM, Igor Vaynberg wrote: > see WicketSessionFilter > > -igor > > On Tue, Aug 4, 2009 at 11:49 AM, Aaron Dixon wrote: >> I am implementing a servlet external to my Wicket application that >> needs to access my Wicket Application instance itself... >> >> Can anyone recommend a clean way to go about this? >> >> - >> 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
Accessing Wicket Application from custom servlet
I am implementing a servlet external to my Wicket application that needs to access my Wicket Application instance itself... Can anyone recommend a clean way to go about this? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: guice-injection on page vs. components
Figured this one out, thanks Igor.
Our pages extended from a base page that was manually injecting
services -- I'm not sure why -- so the components were getting the
proxy and pages were getting the direct instance. I fixed this and
things work perfectly now.
Thanks for your help.
On Fri, Jun 26, 2009 at 12:39 PM, Igor Vaynberg wrote:
> it is wicket-guice module that wraps the service that is retrieved
> from guice with a serializable proxy, not guice itself.
>
> this module treats pages and components exactly the same way because
> page IS A component. i am not sure why pages work differently for you
> if you use the same @Inject annotation and letting the module do the
> injection for you rather then guice itself.
>
> if you take the service that is causing a problem on a page and inject
> that into a component it works fine? can you verify that the thing
> being injected into a page is the wicket serializable proxy rather
> then the direct instance?
>
> -igor
>
> On Fri, Jun 26, 2009 at 10:20 AM, Aaron Dixon wrote:
>> But the nice thing about Guice/Wicket is that you don't have to
>> concern yourself with the serialization problem. And for my non-page
>> components, injection works perfectly. (This is because Guice injects
>> a *serializable* proxy not an actual instance of the service itself.
>> On detach/serialization, the proxy is serialized and on
>> deserializaiton/rehydration, Guice/Wicket will inject the
>> proxy/service again.)
>>
>> So, to reiterate, my problem is that all of this works perfectly for
>> me for any non-page components, but when I @Inject on a Page, the
>> service that is injected is not a proxy and therefore not
>> serializable... and therefore I get the serialization exceptions.
>>
>> Technically Guice IS injecting my service at the page level, it's just
>> injecting the instance itself and not wrapping it a proxy, whereas it
>> IS injecting serializable proxies for non-page components. Why?
>>
>>
>> On Thu, Jun 25, 2009 at 2:04 PM, Mauro Ciancio wrote:
>>> On Wed, Jun 24, 2009 at 1:38 PM, Aaron Dixon wrote:
>>>
>>>>
>>>> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
>>>> Unable to serialize class:
>>>> com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94
>>>> Field hierarchy is:
>>>> 2 [class=com.mycompany.pages.MyPage, path=2]
>>>> private com.mycompany.dao.MyDao
>>>>
>>>> com.mycompany.pages.MyPage.myDao[class=com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94]
>>>> <- field that is not serializable
>>>> at
>>>>
>>>> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:342)
>>>> at
>>>>
>>>> org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:610)
>>>> ...
>>>>
>>>>
>>>> Has anyone else noticed this?
>>>>
>>>
>>> Yes, it happens because the injected class isn't Serializable and when
>>> your page
>>> is serialized the exception is thrown.
>>> You could use for example a
>>> LoadableDetachableModel<http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/model/LoadableDetachableModel.html>to
>>> detach your DAO when
>>> your page is serialized.
>>> Guice also comes with an interface named Provider. This could helps
>>> because it
>>> dont hold a reference to your un-serializable object.
>>>
>>> Example:
>>>
>>> class MyPage extends Page {
>>> LoadableDetachableModel daoModel = new loadable() {
>>> object get() {
>>> return new dao();
>>> }
>>> };
>>>
>>> void something() {
>>> mydao = daoModel.getObject();
>>> //stuff
>>> }
>>>
>>> void ondetach() {
>>> super.ondetach()
>>> daomodel.detach();
>>> }
>>> }
>>>
>>> HTH
>>> Cheers!
>>> --
>>> Mauro Ciancio
>>>
>>
>> -
>> 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: guice-injection on page vs. components
But the nice thing about Guice/Wicket is that you don't have to
concern yourself with the serialization problem. And for my non-page
components, injection works perfectly. (This is because Guice injects
a *serializable* proxy not an actual instance of the service itself.
On detach/serialization, the proxy is serialized and on
deserializaiton/rehydration, Guice/Wicket will inject the
proxy/service again.)
So, to reiterate, my problem is that all of this works perfectly for
me for any non-page components, but when I @Inject on a Page, the
service that is injected is not a proxy and therefore not
serializable... and therefore I get the serialization exceptions.
Technically Guice IS injecting my service at the page level, it's just
injecting the instance itself and not wrapping it a proxy, whereas it
IS injecting serializable proxies for non-page components. Why?
On Thu, Jun 25, 2009 at 2:04 PM, Mauro Ciancio wrote:
> On Wed, Jun 24, 2009 at 1:38 PM, Aaron Dixon wrote:
>
>>
>> org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
>> Unable to serialize class:
>> com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94
>> Field hierarchy is:
>> 2 [class=com.mycompany.pages.MyPage, path=2]
>> private com.mycompany.dao.MyDao
>>
>> com.mycompany.pages.MyPage.myDao[class=com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94]
>> <- field that is not serializable
>> at
>>
>> org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:342)
>> at
>>
>> org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:610)
>> ...
>>
>>
>> Has anyone else noticed this?
>>
>
> Yes, it happens because the injected class isn't Serializable and when
> your page
> is serialized the exception is thrown.
> You could use for example a
> LoadableDetachableModel<http://wicket.apache.org/docs/wicket-1.3.2/wicket/apidocs/org/apache/wicket/model/LoadableDetachableModel.html>to
> detach your DAO when
> your page is serialized.
> Guice also comes with an interface named Provider. This could helps
> because it
> dont hold a reference to your un-serializable object.
>
> Example:
>
> class MyPage extends Page {
> LoadableDetachableModel daoModel = new loadable() {
> object get() {
> return new dao();
> }
> };
>
> void something() {
> mydao = daoModel.getObject();
> //stuff
> }
>
> void ondetach() {
> super.ondetach()
> daomodel.detach();
> }
> }
>
> HTH
> Cheers!
> --
> Mauro Ciancio
>
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
guice-injection on page vs. components
Hello, all -
Guice/Wicket integration is excellent, but doesn't seem to work properly
when I use @Inject-ed services on my *page* classes. It only seems to work
when I inject services on components of my pages. I get
WicketNotSerializableExceptions for services that I inject on my page class
instances.
So, if this is my page class:
public class MyPage extends WebPage {
@Inject
private MyDao myDao; // causes WicketNotSerializableException
public MyPage() {
add(new MyPanel() {
@Inject
private MyDao myDao; // works fine and dandy
...
}
}
}
I get:
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
Unable to serialize class:
com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94
Field hierarchy is:
2 [class=com.mycompany.pages.MyPage, path=2]
private com.mycompany.dao.MyDao
com.mycompany.pages.MyPage.myDao[class=com.mycompany.dao.MyDao$$EnhancerByGuice$$3e6e9f94]
<- field that is not serializable
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:342)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:610)
...
Has anyone else noticed this?
Re: redirect to mailto
Thanks, Erik. But I need to have this behavior initiated in response
to an ajax event (say, on an onchange for a select drop down).
On Mon, Jun 22, 2009 at 2:00 PM, Erik van Oosten wrote:
> You can use ExternalLink with a mailto: url.
>
> Regards,
> Erik.
>
> Aaron Dixon wrote:
>>
>> How do I redirect to a mailto: url? This doesn't seem to work:
>>
>> final String url = "mailto:...";;
>> getRequestCycle().setRequestTarget(new IRequestTarget()
>> {
>> �...@override
>> public void detach(RequestCycle requestCycle) {}
>> �...@override
>> public void respond(RequestCycle requestCycle) {
>> Response response = requestCycle.getResponse();
>> response.reset();
>> response.redirect(url);
>> }
>> });
>>
>>
>
>
> -
> 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
redirect to mailto
How do I redirect to a mailto: url? This doesn't seem to work:
final String url = "mailto:...";;
getRequestCycle().setRequestTarget(new IRequestTarget() {
@Override
public void detach(RequestCycle requestCycle) {}
@Override
public void respond(RequestCycle requestCycle) {
Response response = requestCycle.getResponse();
response.reset();
response.redirect(url);
}
});
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: using a guice-injected service in a created thread
But then I need an injector in that context...I suppose the suggestion is to
inject the injector into MyPanel?
@Inject
Injector injector;
It looks funny, but probably cleaner than pulling the services.
On Mon, Jun 15, 2009 at 3:56 PM, Igor Vaynberg wrote:
> why not simply have MyThread injected by guice...
>
> Thread t=injector.getinstance(MyThread.class);
>
> -igor
>
> On Mon, Jun 15, 2009 at 1:34 PM, Aaron Dixon wrote:
> > I'm using Guice component injection with Wicket and it works grreat:
> >
> > MyPanel {
> >
> >@Inject
> >private MyService myService;
> >
> >MyPanel(String id) {
> >super(id);
> >myService.doSomething();
> >}
> >
> >//...
> > }
> >
> > HOWEVER, now I'm tryin' to send my service to a thread that I create,
> like
> > so:
> >
> > MyPanel {
> >
> >@Inject
> >private MyService myService;
> >
> >MyPanel(String id) {
> >super(id);
> >myService.doSomething();
> >}
> >
> >void onEvent() {
> >Thread t = new MyThread(myService) {
> >
> >// ...uses passed-in myService in run() method
> >
> >}
> >}
> > }
> >
> > BUT of course Guice is proxying my service and it doesn't expect it in a
> > non-Wicket thread. At runtime I get:
> >
> > org.apache.wicket.WicketRuntimeException: There is no application
> attached
> > to current thread pool-1-thread-1
> >at org.apache.wicket.Application.get(Application.java:166)
> >at
> >
> org.apache.wicket.guice.GuiceProxyTargetLocator.locateProxyTarget(GuiceProxyTargetLocator.java:48)
> >at
> >
> org.apache.wicket.proxy.LazyInitProxyFactory$CGLibInterceptor.intercept(LazyInitProxyFactory.java:316)
> >at
> >
> WICKET_com.conducive.data.dao.MyService$$EnhancerByCGLIB$$6fc4e9bf.getManagedSession()
> >at
> >
> com.conducive.ui.userPages.monitor.result.MyThread.run(MonitorRetrieverTask.java:33)
> >at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> >at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> >at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> >at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> >at
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> >at java.lang.Thread.run(Thread.java:619)
> >
> > This makes sense to me why this is happening (Guice/Wicket need a Wicket
> > context to deserialize the instance).
> >
> > SO, I guess this means I have to pull-and-set those services on the
> thread
> > myself...unless there is a better way?
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
using a guice-injected service in a created thread
I'm using Guice component injection with Wicket and it works grreat:
MyPanel {
@Inject
private MyService myService;
MyPanel(String id) {
super(id);
myService.doSomething();
}
//...
}
HOWEVER, now I'm tryin' to send my service to a thread that I create, like
so:
MyPanel {
@Inject
private MyService myService;
MyPanel(String id) {
super(id);
myService.doSomething();
}
void onEvent() {
Thread t = new MyThread(myService) {
// ...uses passed-in myService in run() method
}
}
}
BUT of course Guice is proxying my service and it doesn't expect it in a
non-Wicket thread. At runtime I get:
org.apache.wicket.WicketRuntimeException: There is no application attached
to current thread pool-1-thread-1
at org.apache.wicket.Application.get(Application.java:166)
at
org.apache.wicket.guice.GuiceProxyTargetLocator.locateProxyTarget(GuiceProxyTargetLocator.java:48)
at
org.apache.wicket.proxy.LazyInitProxyFactory$CGLibInterceptor.intercept(LazyInitProxyFactory.java:316)
at
WICKET_com.conducive.data.dao.MyService$$EnhancerByCGLIB$$6fc4e9bf.getManagedSession()
at
com.conducive.ui.userPages.monitor.result.MyThread.run(MonitorRetrieverTask.java:33)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
This makes sense to me why this is happening (Guice/Wicket need a Wicket
context to deserialize the instance).
SO, I guess this means I have to pull-and-set those services on the thread
myself...unless there is a better way?
nested onclick events
If there is no Wicket-centric answer to this, it's a Javascript question.
I have an AjaxEventBehavior("onclick") behaviored attached to a
wicket-rendered table/tr.
I am trying to render html links within each rendered item, and not
have the wicket-onclick behavior executed if the user clicks on a link
within the itm.
The typical solution I found online is some variation of the following
used for the onclick property of the generated links:
e = window.event; e.cancelBubble = true; e.returnValue = false;
if (e.stopPropagation) { e.stopPropagation(); e.preventDefault(); }
return false;
However this isn't working, and it doesn't seem Wicket-centric either.
Any experience out there with this event bubble-up problem?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
