Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Dieter Tremel]

Am 17.06.2016 um 12:58 schrieb Bas Gooren:
> Although I do wonder why you are trying to cache JPA objects by yourself -
> you could simply plug in a second level cache to your JPA provider. Then it
> will cache transparently.

Didn't know, activated JPA second level cache, works well, dropped my
Caching implementation. ;-)

In German I say "Wissen ist Macht, wir wissen nichts, macht nichts"

Thank You
Dieter

-- 
Tremel Computerhttp://www.tremel-computer.de
Dieter Tremel  mailto:tre...@tremel-computer.de
Rebenring 16   Tel +49 871 9357080
84032 Altdorf  Fax +49 871 9357081

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Bas Gooren]

Hi Dieter,


That’s what I expected (and why I did not recommend it); The error you see
is because somewhere in the component tree inside your page serialization
breaks. Since it happens when wicket passes the page to an (internal)
ObjectOutputStream, the only way to debug it would be to set a breakpoint
inside the OOS. As Martin recommends, you can do so in the future.


Happy to hear you found the root cause of your problem!


Although I do wonder why you are trying to cache JPA objects by yourself -
you could simply plug in a second level cache to your JPA provider. Then it
will cache transparently.

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 17 juni 2016 bij 12:38:00, Dieter Tremel (tre...@tremel-computer.de)
schreef:

Hello Martin,

I tried this to learn it, but didn't find it.

I put a breakpoint at org.apache.wicket.serialize.java.JavaSerializer
SerializationCheckerObjectOutputStream#writeObjectOverride line 260 and
277 and looked at the variables content.

The obj was the complete page PersonenTable and I had to look at all the
children in the page hierarchy. Not straight forward to find.

Did I miss something?

Thanks Dieter

Am 17.06.2016 um 11:56 schrieb Martin Grigorov:
> Hi Dieter,
> br/>> It is quite easy to debug such issues by puttinng a breakpoint at
line where
> the exception is being thrown.
> Once you have the debugger stopped there you could click on the stack
> methods to see what was the parent object of the currently failing one.
> br/>> Martin Grigorov <
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> br/>> On FFri, Jun 17, 2016 at 11:46 AM, Dieter Tremel <
tre...@tremel-computer.de>
> wrote:
> br/>>> Hello Bas, <
>>
>> first of all let me thank you and Martin for your great support and the
>> helpful thoughts and examples :-)
>>
>> I am using wicket 7.30, the use of onBefore() is an old pattern I have
>> been used to, changed it now to
>> @Override
>> protected void onInitialize() {
>> super.onInitialize();
>> initMarkup();
>> }
>> on all pages.
>>
>> The last days I spent a lot of time in analyzing, debugging, some
>> refactoring, searching. But I didn't find the culprit yet. :-(
>>
>> Your example is useful, I read some similar blogpost about outside final
>> vars in methods of anonymous inner classes, but had no match in my code
>> so far.
>>
>> I will do some more exhaustive search and report, if I solved the
problem.
>>
>> Thank You
>> Dieter
>>
>> Am 16.06.2016 um 16:32 schrieb Bas Gooren:
>>> Hi Dieter,
>>>
>>>
>>> Which version of wicket are you using? (I ask since I see you are using
>>> onBeforeRender() to initialize your components, while since wicket 1.5
>>> there is onInitialize() for that in each component).
>>>
>>>
>>> For as far as I can see there are no references to your dao in the gist
>>> you provided; However, since it is serialized somewhere in the
component
>>> tree, it could be in one of the smaller components used in your
>>> PersonenTable page.
>>>
>>> In any case, your page (or a component inside it) has a reference to
>>> your dao.
>>>
>>>
>>> Since I’ve seen this a lot when I started using wicket, please check if
>>> you are referencing your dao somewhere inside an anonymous inner class
/
>>> component.
>>>
>>>
>>> E.g.:
>>>
>>>
>>> public Component createMyComponent(String id) {
>>>
>>> DAO dao = getDaoFromPageOrElsewhere();
>>>
>>> return new AjaxLink(id) {
>>>
>>> public void onClick(AjaxRequestTarget target) {
>>>
>>> // This is where an instance of DAO will get serialized into the
>>> component tree!
>>>
>>> dao.performAction();
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> Rewrite such code (if you have it) to look up the DAO reference at the
>>> time you actually need it:
>>>
>>>
>>> public void onClick(AjaxRequestTarget target) {
>>>
>>> DAO dao = getDaoFromPageOrElsewhere();
>>>
>>> dao.performAction();
>>>
>>> }
>>>
>>>
>>> My guess is that you’ll find the culprit by simply looking at all
places
>>> in your code where you use the PersonenDao.
>>>
>>>
>>> Met vriendelijke groet,
>>> Kind regards,
>>>
>>> Bas Gooren
>>>
>>> Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de
>>> ) schreef:
>>>
 Hello Martin,

 it is:

 personenProvider = (com.sun.proxy.$Proxy24)
 org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea

 wrapInProxies is true

 I added a SignIn mechanism, SignInSession uses PersonenDao too to
 authorize in the database. But I checked not to have any references to
 it, that could be serialized. I added more of this this part to the
>> gist:

 https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29

 Dieter

 Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
> Hi,
>
> Put a breakpoint at PersonenTable constructor and see what is the
>> type of '
> personenProvider'.
> It must be JDK Proxy instance.
> If it is not then something wrong is going 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Martin Grigorov]

Do you see java.io.ObjectOutputStream#writeObject0() in the stack ?
Each occurrence of this method gives you information about the currently
being written object. The next occurrence of this method in the stack tells
you which Java object is the owner of the previous one.
I don't have time now to make a screencast :-/

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Jun 17, 2016 at 12:37 PM, Dieter Tremel 
wrote:

> Hello Martin,
>
> I tried this to learn it, but didn't find it.
>
> I put a breakpoint at org.apache.wicket.serialize.java.JavaSerializer
> SerializationCheckerObjectOutputStream#writeObjectOverride line 260 and
> 277 and looked at the variables content.
>
> The obj was the complete page PersonenTable and I had to look at all the
> children in the page hierarchy. Not straight forward to find.
>
> Did I miss something?
>
> Thanks Dieter
>
> Am 17.06.2016 um 11:56 schrieb Martin Grigorov:
> > Hi Dieter,
> >
> > It is quite easy to debug such issues by putting a breakpoint at line
> where
> > the exception is being thrown.
> > Once you have the debugger stopped there you could click on the stack
> > methods to see what was the parent object of the currently failing one.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Fri, Jun 17, 2016 at 11:46 AM, Dieter Tremel <
> tre...@tremel-computer.de>
> > wrote:
> >
> >> Hello Bas,
> >>
> >> first of all let me thank you and Martin for your great support and the
> >> helpful thoughts and examples :-)
> >>
> >> I am using wicket 7.30, the use of onBefore() is an old pattern I have
> >> been used to, changed it now to
> >> @Override
> >> protected void onInitialize() {
> >> super.onInitialize();
> >> initMarkup();
> >> }
> >> on all pages.
> >>
> >> The last days I spent a lot of time in analyzing, debugging, some
> >> refactoring, searching. But I didn't find the culprit yet. :-(
> >>
> >> Your example is useful, I read some similar blogpost about outside final
> >> vars in methods of anonymous inner classes, but had no match in my code
> >> so far.
> >>
> >> I will do some more exhaustive search and report, if I solved the
> problem.
> >>
> >> Thank You
> >> Dieter
> >>
> >> Am 16.06.2016 um 16:32 schrieb Bas Gooren:
> >>> Hi Dieter,
> >>>
> >>>
> >>> Which version of wicket are you using? (I ask since I see you are using
> >>> onBeforeRender() to initialize your components, while since wicket 1.5
> >>> there is onInitialize() for that in each component).
> >>>
> >>>
> >>> For as far as I can see there are no references to your dao in the gist
> >>> you provided; However, since it is serialized somewhere in the
> component
> >>> tree, it could be in one of the smaller components used in your
> >>> PersonenTable page.
> >>>
> >>> In any case, your page (or a component inside it) has a reference to
> >>> your dao.
> >>>
> >>>
> >>> Since I’ve seen this a lot when I started using wicket, please check if
> >>> you are referencing your dao somewhere inside an anonymous inner class
> /
> >>> component.
> >>>
> >>>
> >>> E.g.:
> >>>
> >>>
> >>> public Component createMyComponent(String id) {
> >>>
> >>> DAO dao = getDaoFromPageOrElsewhere();
> >>>
> >>> return new AjaxLink(id) {
> >>>
> >>> public void onClick(AjaxRequestTarget target) {
> >>>
> >>> // This is where an instance of DAO will get serialized into the
> >>> component tree!
> >>>
> >>> dao.performAction();
> >>>
> >>> }
> >>>
> >>> }
> >>>
> >>> }
> >>>
> >>>
> >>> Rewrite such code (if you have it) to look up the DAO reference at the
> >>> time you actually need it:
> >>>
> >>>
> >>> public void onClick(AjaxRequestTarget target) {
> >>>
> >>> DAO dao = getDaoFromPageOrElsewhere();
> >>>
> >>> dao.performAction();
> >>>
> >>> }
> >>>
> >>>
> >>> My guess is that you’ll find the culprit by simply looking at all
> places
> >>> in your code where you use the PersonenDao.
> >>>
> >>>
> >>> Met vriendelijke groet,
> >>> Kind regards,
> >>>
> >>> Bas Gooren
> >>>
> >>> Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de
> >>> ) schreef:
> >>>
>  Hello Martin,
> 
>  it is:
> 
>  personenProvider = (com.sun.proxy.$Proxy24)
>  org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea
> 
>  wrapInProxies is true
> 
>  I added a SignIn mechanism, SignInSession uses PersonenDao too to
>  authorize in the database. But I checked not to have any references to
>  it, that could be serialized. I added more of this this part to the
> >> gist:
> 
>  https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29
> 
>  Dieter
> 
>  Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
> > Hi,
> >
> > Put a breakpoint at PersonenTable constructor and see what is the
> >> type of '
> > personenProvider'.
> > It must be JDK Proxy 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Dieter Tremel]

Hello Martin,

I tried this to learn it, but didn't find it.

I put a breakpoint at org.apache.wicket.serialize.java.JavaSerializer
SerializationCheckerObjectOutputStream#writeObjectOverride line 260 and
277 and looked at the variables content.

The obj was the complete page PersonenTable and I had to look at all the
children in the page hierarchy. Not straight forward to find.

Did I miss something?

Thanks Dieter

Am 17.06.2016 um 11:56 schrieb Martin Grigorov:
> Hi Dieter,
> 
> It is quite easy to debug such issues by putting a breakpoint at line where
> the exception is being thrown.
> Once you have the debugger stopped there you could click on the stack
> methods to see what was the parent object of the currently failing one.
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Fri, Jun 17, 2016 at 11:46 AM, Dieter Tremel 
> wrote:
> 
>> Hello Bas,
>>
>> first of all let me thank you and Martin for your great support and the
>> helpful thoughts and examples :-)
>>
>> I am using wicket 7.30, the use of onBefore() is an old pattern I have
>> been used to, changed it now to
>> @Override
>> protected void onInitialize() {
>> super.onInitialize();
>> initMarkup();
>> }
>> on all pages.
>>
>> The last days I spent a lot of time in analyzing, debugging, some
>> refactoring, searching. But I didn't find the culprit yet. :-(
>>
>> Your example is useful, I read some similar blogpost about outside final
>> vars in methods of anonymous inner classes, but had no match in my code
>> so far.
>>
>> I will do some more exhaustive search and report, if I solved the problem.
>>
>> Thank You
>> Dieter
>>
>> Am 16.06.2016 um 16:32 schrieb Bas Gooren:
>>> Hi Dieter,
>>>
>>>
>>> Which version of wicket are you using? (I ask since I see you are using
>>> onBeforeRender() to initialize your components, while since wicket 1.5
>>> there is onInitialize() for that in each component).
>>>
>>>
>>> For as far as I can see there are no references to your dao in the gist
>>> you provided; However, since it is serialized somewhere in the component
>>> tree, it could be in one of the smaller components used in your
>>> PersonenTable page.
>>>
>>> In any case, your page (or a component inside it) has a reference to
>>> your dao.
>>>
>>>
>>> Since I’ve seen this a lot when I started using wicket, please check if
>>> you are referencing your dao somewhere inside an anonymous inner class /
>>> component.
>>>
>>>
>>> E.g.:
>>>
>>>
>>> public Component createMyComponent(String id) {
>>>
>>> DAO dao = getDaoFromPageOrElsewhere();
>>>
>>> return new AjaxLink(id) {
>>>
>>> public void onClick(AjaxRequestTarget target) {
>>>
>>> // This is where an instance of DAO will get serialized into the
>>> component tree!
>>>
>>> dao.performAction();
>>>
>>> }
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> Rewrite such code (if you have it) to look up the DAO reference at the
>>> time you actually need it:
>>>
>>>
>>> public void onClick(AjaxRequestTarget target) {
>>>
>>> DAO dao = getDaoFromPageOrElsewhere();
>>>
>>> dao.performAction();
>>>
>>> }
>>>
>>>
>>> My guess is that you’ll find the culprit by simply looking at all places
>>> in your code where you use the PersonenDao.
>>>
>>>
>>> Met vriendelijke groet,
>>> Kind regards,
>>>
>>> Bas Gooren
>>>
>>> Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de
>>> ) schreef:
>>>
 Hello Martin,

 it is:

 personenProvider = (com.sun.proxy.$Proxy24)
 org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea

 wrapInProxies is true

 I added a SignIn mechanism, SignInSession uses PersonenDao too to
 authorize in the database. But I checked not to have any references to
 it, that could be serialized. I added more of this this part to the
>> gist:

 https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29

 Dieter

 Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
> Hi,
>
> Put a breakpoint at PersonenTable constructor and see what is the
>> type of '
> personenProvider'.
> It must be JDK Proxy instance.
> If it is not then something wrong is going on.
>
>
>> org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,
> com.google.inject.Injector, boolean) - the last parameter here is
> 'wrapInProxies'. It must be 'true'.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel <
>> tre...@tremel-computer.de >
> wrote:
>
>> Hi Bas,
>>
>> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
>>
>> I fear it is not really useful, since it starts with
>>
>> org.apache.wicket.WicketRuntimeException: A problem occurred while
>> trying to 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Dieter Tremel]

Hello,

I think I have found it:

In my AbstractProvider superclass I implemented:
@Override
public IModel model(E object) {
return new JPAEntityModel<>((E) object);
}

PersonenTable uses a CachingProvider, a subclass of AbstractProvider
which overwrites
@Override
public IModel model(E entity) {
return new AbiProviderModel(this, entity);
}

which is implemented as:

public class AbiProviderModel extends
LoadableDetachableModel {

private static final long serialVersionUID = 1L;
private final IAbiDataProvider provider;
private final Object id;

public AbiProviderModel(IAbiDataProvider provider, E instance) {
super(instance);
this.provider = provider;
this.id = instance.getUniqueId();
}

public AbiProviderModel(IAbiDataProvider provider, Object id) {
super();
this.provider = provider;
this.id = id;
}

@Override
protected E load() {
return provider.find(id);
}
}

Here the embedded provider is the problem!

I replaced this with a JPAEntityModel again, and it works without
serialization error. I am unburdened but ashamed it took so long to find.

But this does not make use of the cache. Perhaps I will refactor my code
not to make the provider holding the cache, but the dao itself.

Thank You for your help!
Dieter

Am 16.06.2016 um 16:32 schrieb Bas Gooren:
> Hi Dieter,
> 
> 
> Which version of wicket are you using? (I ask since I see you are using
> onBeforeRender() to initialize your components, while since wicket 1.5
> there is onInitialize() for that in each component).
> 
> 
> For as far as I can see there are no references to your dao in the gist you
> provided; However, since it is serialized somewhere in the component tree,
> it could be in one of the smaller components used in your PersonenTable
> page.
> 
> In any case, your page (or a component inside it) has a reference to your
> dao.
> 
> 
> Since I’ve seen this a lot when I started using wicket, please check if you
> are referencing your dao somewhere inside an anonymous inner class /
> component.
> 
> 
> E.g.:
> 
> 
> public Component createMyComponent(String id) {
> 
> DAO dao = getDaoFromPageOrElsewhere();
> 
> return new AjaxLink(id) {
> 
> public void onClick(AjaxRequestTarget target) {
> 
> // This is where an instance of DAO will get serialized into the component
> tree!
> 
> dao.performAction();
> 
> }
> 
> }
> 
> }
> 
> 
> Rewrite such code (if you have it) to look up the DAO reference at the time
> you actually need it:
> 
> 
> public void onClick(AjaxRequestTarget target) {
> 
> DAO dao = getDaoFromPageOrElsewhere();
> 
> dao.performAction();
> 
> }
> 
> 
> My guess is that you’ll find the culprit by simply looking at all places in
> your code where you use the PersonenDao.
> 
> 
> Met vriendelijke groet,
> Kind regards,
> 
> Bas Gooren
> 
> Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de)
> schreef:
> 
> Hello Martin,
> 
> it is:
> 
> personenProvider = (com.sun.proxy.$Proxy24)
> org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea
> 
> wrapInProxies is true
> 
> I added a SignIn mechanism, SignInSession uses PersonenDao too to
> authorize in the database. But I checked not to have any references to
> it, that could be serialized. I added more of this this part to the gist:
> 
> https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29
> 
> Dieter
> 
> Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
>> Hi,
>>
>> Put a breakpoint at PersonenTable constructor and see what is the type of
> '
>> personenProvider'.
>> It must be JDK Proxy instance.
>> If it is not then something wrong is going on.
>>
>>
> org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,
> 
>> com.google.inject.Injector, boolean) - the last parameter here is
>> 'wrapInProxies'. It must be 'true'.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel 
> 
>> wrote:
>>
>>> Hi Bas,
>>>
>>> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
>>>
>>> I fear it is not really useful, since it starts with
>>>
>>> org.apache.wicket.WicketRuntimeException: A problem occurred while
>>> trying to collect debug information about not serializable object
>>>
>>> Dieter
>>>
>>> Am 15.06.2016 um 13:39 schrieb Bas Gooren:
 Hi Dieter,

 Can you share the stack trace of the serialization checker error?
 Normally it points out where in the hierarchy it found a
 non-serializable object.
 My first guess is that you are referencing the dao class somewhere
 directly from your page. The stack trace will prove me right or wrong
> :-)

 Met vriendelijke groet,
 Kind regards,

 Bas Gooren

 Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de
 ) 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Martin Grigorov]

Hi Dieter,

It is quite easy to debug such issues by putting a breakpoint at line where
the exception is being thrown.
Once you have the debugger stopped there you could click on the stack
methods to see what was the parent object of the currently failing one.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Fri, Jun 17, 2016 at 11:46 AM, Dieter Tremel 
wrote:

> Hello Bas,
>
> first of all let me thank you and Martin for your great support and the
> helpful thoughts and examples :-)
>
> I am using wicket 7.30, the use of onBefore() is an old pattern I have
> been used to, changed it now to
> @Override
> protected void onInitialize() {
> super.onInitialize();
> initMarkup();
> }
> on all pages.
>
> The last days I spent a lot of time in analyzing, debugging, some
> refactoring, searching. But I didn't find the culprit yet. :-(
>
> Your example is useful, I read some similar blogpost about outside final
> vars in methods of anonymous inner classes, but had no match in my code
> so far.
>
> I will do some more exhaustive search and report, if I solved the problem.
>
> Thank You
> Dieter
>
> Am 16.06.2016 um 16:32 schrieb Bas Gooren:
> > Hi Dieter,
> >
> >
> > Which version of wicket are you using? (I ask since I see you are using
> > onBeforeRender() to initialize your components, while since wicket 1.5
> > there is onInitialize() for that in each component).
> >
> >
> > For as far as I can see there are no references to your dao in the gist
> > you provided; However, since it is serialized somewhere in the component
> > tree, it could be in one of the smaller components used in your
> > PersonenTable page.
> >
> > In any case, your page (or a component inside it) has a reference to
> > your dao.
> >
> >
> > Since I’ve seen this a lot when I started using wicket, please check if
> > you are referencing your dao somewhere inside an anonymous inner class /
> > component.
> >
> >
> > E.g.:
> >
> >
> > public Component createMyComponent(String id) {
> >
> > DAO dao = getDaoFromPageOrElsewhere();
> >
> > return new AjaxLink(id) {
> >
> > public void onClick(AjaxRequestTarget target) {
> >
> > // This is where an instance of DAO will get serialized into the
> > component tree!
> >
> > dao.performAction();
> >
> > }
> >
> > }
> >
> > }
> >
> >
> > Rewrite such code (if you have it) to look up the DAO reference at the
> > time you actually need it:
> >
> >
> > public void onClick(AjaxRequestTarget target) {
> >
> > DAO dao = getDaoFromPageOrElsewhere();
> >
> > dao.performAction();
> >
> > }
> >
> >
> > My guess is that you’ll find the culprit by simply looking at all places
> > in your code where you use the PersonenDao.
> >
> >
> > Met vriendelijke groet,
> > Kind regards,
> >
> > Bas Gooren
> >
> > Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de
> > ) schreef:
> >
> >> Hello Martin,
> >>
> >> it is:
> >>
> >> personenProvider = (com.sun.proxy.$Proxy24)
> >> org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea
> >>
> >> wrapInProxies is true
> >>
> >> I added a SignIn mechanism, SignInSession uses PersonenDao too to
> >> authorize in the database. But I checked not to have any references to
> >> it, that could be serialized. I added more of this this part to the
> gist:
> >>
> >> https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29
> >>
> >> Dieter
> >>
> >> Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
> >> > Hi,
> >> >
> >> > Put a breakpoint at PersonenTable constructor and see what is the
> type of '
> >> > personenProvider'.
> >> > It must be JDK Proxy instance.
> >> > If it is not then something wrong is going on.
> >> >
> >> >
> org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,
> >> > com.google.inject.Injector, boolean) - the last parameter here is
> >> > 'wrapInProxies'. It must be 'true'.
> >> >
> >> > Martin Grigorov
> >> > Wicket Training and Consulting
> >> > https://twitter.com/mtgrigorov
> >> >
> >> > On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel <
> tre...@tremel-computer.de >
> >> > wrote:
> >> >
> >> >> Hi Bas,
> >> >>
> >> >> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
> >> >>
> >> >> I fear it is not really useful, since it starts with
> >> >>
> >> >> org.apache.wicket.WicketRuntimeException: A problem occurred while
> >> >> trying to collect debug information about not serializable object
> >> >>
> >> >> Dieter
> >> >>
> >> >> Am 15.06.2016 um 13:39 schrieb Bas Gooren:
> >> >>> Hi Dieter,
> >> >>>
> >> >>> Can you share the stack trace of the serialization checker error?
> >> >>> Normally it points out where in the hierarchy it found a
> >> >>> non-serializable object.
> >> >>> My first guess is that you are referencing the dao class somewhere
> >> >>> directly from your page. The stack trace will prove me right or
> wrong 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Dieter Tremel]

Hello Bas,

first of all let me thank you and Martin for your great support and the
helpful thoughts and examples :-)

I am using wicket 7.30, the use of onBefore() is an old pattern I have
been used to, changed it now to
@Override
protected void onInitialize() {
super.onInitialize();
initMarkup();
}
on all pages.

The last days I spent a lot of time in analyzing, debugging, some
refactoring, searching. But I didn't find the culprit yet. :-(

Your example is useful, I read some similar blogpost about outside final
vars in methods of anonymous inner classes, but had no match in my code
so far.

I will do some more exhaustive search and report, if I solved the problem.

Thank You
Dieter

Am 16.06.2016 um 16:32 schrieb Bas Gooren:
> Hi Dieter,
> 
> 
> Which version of wicket are you using? (I ask since I see you are using
> onBeforeRender() to initialize your components, while since wicket 1.5
> there is onInitialize() for that in each component).
> 
> 
> For as far as I can see there are no references to your dao in the gist
> you provided; However, since it is serialized somewhere in the component
> tree, it could be in one of the smaller components used in your
> PersonenTable page.
> 
> In any case, your page (or a component inside it) has a reference to
> your dao.
> 
> 
> Since I’ve seen this a lot when I started using wicket, please check if
> you are referencing your dao somewhere inside an anonymous inner class /
> component.
> 
> 
> E.g.:
> 
> 
> public Component createMyComponent(String id) {
> 
> DAO dao = getDaoFromPageOrElsewhere();
> 
> return new AjaxLink(id) {
> 
> public void onClick(AjaxRequestTarget target) {
> 
> // This is where an instance of DAO will get serialized into the
> component tree!
> 
> dao.performAction();
> 
> }
> 
> }
> 
> }
> 
> 
> Rewrite such code (if you have it) to look up the DAO reference at the
> time you actually need it:
> 
> 
> public void onClick(AjaxRequestTarget target) {
> 
> DAO dao = getDaoFromPageOrElsewhere();
> 
> dao.performAction();
> 
> }
> 
> 
> My guess is that you’ll find the culprit by simply looking at all places
> in your code where you use the PersonenDao.
> 
> 
> Met vriendelijke groet,
> Kind regards,
> 
> Bas Gooren
> 
> Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de
> ) schreef:
> 
>> Hello Martin,
>>
>> it is:
>>
>> personenProvider = (com.sun.proxy.$Proxy24)
>> org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea
>>
>> wrapInProxies is true
>>
>> I added a SignIn mechanism, SignInSession uses PersonenDao too to
>> authorize in the database. But I checked not to have any references to
>> it, that could be serialized. I added more of this this part to the gist:
>>
>> https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29
>>
>> Dieter
>>
>> Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
>> > Hi,
>> >  
>> > Put a breakpoint at PersonenTable constructor and see what is the type of '
>> > personenProvider'.
>> > It must be JDK Proxy instance.
>> > If it is not then something wrong is going on.
>> >  
>> > org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,
>> > com.google.inject.Injector, boolean) - the last parameter here is
>> > 'wrapInProxies'. It must be 'true'.
>> >  
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>> >  
>> > On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel > > >
>> > wrote:
>> >  
>> >> Hi Bas,
>> >>
>> >> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
>> >>
>> >> I fear it is not really useful, since it starts with
>> >>
>> >> org.apache.wicket.WicketRuntimeException: A problem occurred while
>> >> trying to collect debug information about not serializable object
>> >>
>> >> Dieter
>> >>
>> >> Am 15.06.2016 um 13:39 schrieb Bas Gooren:
>> >>> Hi Dieter,
>> >>>
>> >>> Can you share the stack trace of the serialization checker error?
>> >>> Normally it points out where in the hierarchy it found a
>> >>> non-serializable object.
>> >>> My first guess is that you are referencing the dao class somewhere
>> >>> directly from your page. The stack trace will prove me right or wrong :-)
>> >>>
>> >>> Met vriendelijke groet,
>> >>> Kind regards,
>> >>>
>> >>> Bas Gooren
>> >>>
>> >>> Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de 
>> >>> 
>> >>> >) 
>> >>> schreef:
>> >>>
>>  Hello Bas,
>> 
>>  I try to cut small pieces of the code, please tell me if you want to see
>>  more.
>> 
>>  First the error:
>> 
>>  12:59:03.919 [http-nio-8084-exec-6] WARN
>>  o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to
>>  writeObject :
>> 
>> >> 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Bas Gooren]

Hi Dieter,


Which version of wicket are you using? (I ask since I see you are using
onBeforeRender() to initialize your components, while since wicket 1.5
there is onInitialize() for that in each component).


For as far as I can see there are no references to your dao in the gist you
provided; However, since it is serialized somewhere in the component tree,
it could be in one of the smaller components used in your PersonenTable
page.

In any case, your page (or a component inside it) has a reference to your
dao.


Since I’ve seen this a lot when I started using wicket, please check if you
are referencing your dao somewhere inside an anonymous inner class /
component.


E.g.:


public Component createMyComponent(String id) {

DAO dao = getDaoFromPageOrElsewhere();

return new AjaxLink(id) {

public void onClick(AjaxRequestTarget target) {

// This is where an instance of DAO will get serialized into the component
tree!

dao.performAction();

}

}

}


Rewrite such code (if you have it) to look up the DAO reference at the time
you actually need it:


public void onClick(AjaxRequestTarget target) {

DAO dao = getDaoFromPageOrElsewhere();

dao.performAction();

}


My guess is that you’ll find the culprit by simply looking at all places in
your code where you use the PersonenDao.


Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 15 juni 2016 bij 16:25:25, Dieter Tremel (tre...@tremel-computer.de)
schreef:

Hello Martin,

it is:

personenProvider = (com.sun.proxy.$Proxy24)
org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea

wrapInProxies is true

I added a SignIn mechanism, SignInSession uses PersonenDao too to
authorize in the database. But I checked not to have any references to
it, that could be serialized. I added more of this this part to the gist:

https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29

Dieter

Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
> Hi,
>
> Put a breakpoint at PersonenTable constructor and see what is the type of
'
> personenProvider'.
> It must be JDK Proxy instance.
> If it is not then something wrong is going on.
>
>
org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,

> com.google.inject.Injector, boolean) - the last parameter here is
> 'wrapInProxies'. It must be 'true'.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel 

> wrote:
>
>> Hi Bas,
>>
>> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
>>
>> I fear it is not really useful, since it starts with
>>
>> org.apache.wicket.WicketRuntimeException: A problem occurred while
>> trying to collect debug information about not serializable object
>>
>> Dieter
>>
>> Am 15.06.2016 um 13:39 schrieb Bas Gooren:
>>> Hi Dieter,
>>>
>>> Can you share the stack trace of the serialization checker error?
>>> Normally it points out where in the hierarchy it found a
>>> non-serializable object.
>>> My first guess is that you are referencing the dao class somewhere
>>> directly from your page. The stack trace will prove me right or wrong
:-)
>>>
>>> Met vriendelijke groet,
>>> Kind regards,
>>>
>>> Bas Gooren
>>>
>>> Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de
>>> ) schreef:
>>>
 Hello Bas,

 I try to cut small pieces of the code, please tell me if you want to
see
 more.

 First the error:

 12:59:03.919 [http-nio-8084-exec-6] WARN
 o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to
 writeObject :

>>
de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f,


 path: /children
 12:59:03.925 [http-nio-8084-exec-6] ERROR
 o.a.w.serialize.java.JavaSerializer - Error serializing object class
 de.tremel_computer.abi81.pages.PersonenTable [object=[Page class =
 de.tremel_computer.abi81.pages.PersonenTable, id = 1, render count =
1]]
 org.apache.wicket.WicketRuntimeException: A problem occurred while
 trying to collect debug information about not serializable object
 at

>>
org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:278)





 public class PersonenTable extends BasePage {

 @Inject
 private ICachingAbiDataProvider personenProvider;
 ...
 }

 public class AbstractProvider extends
 SortableDataProvider implements IAbiDataProvider {

 @Inject
 private ReadOnlyDao dao;
 ...
 }

 public abstract class JPAReadOnlyDao implements
 ReadOnlyDao {

 private Provider emProvider;
 private final Class entityClass;

 public JPAReadOnlyDao(Class entityClass) {
 this.entityClass = entityClass;
 }
 ...

 @Inject
 public void setEntityManagerProvider(Provider
 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Dieter Tremel]

Hello Martin,

it is:

personenProvider = (com.sun.proxy.$Proxy24)
org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler@6eb3b9ea

wrapInProxies is true

I added a SignIn mechanism, SignInSession uses PersonenDao too to
authorize in the database. But I checked not to have any references to
it, that could be serialized. I added more of this this part to the gist:

https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29

Dieter

Am 15.06.2016 um 15:00 schrieb Martin Grigorov:
> Hi,
> 
> Put a breakpoint at PersonenTable constructor and see what is the type of '
> personenProvider'.
> It must be JDK Proxy instance.
> If it is not then something wrong is going on.
> 
> org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,
> com.google.inject.Injector, boolean) - the last parameter here is
> 'wrapInProxies'. It must be 'true'.
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel 
> wrote:
> 
>> Hi Bas,
>>
>> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
>>
>> I fear it is not really useful, since it starts with
>>
>> org.apache.wicket.WicketRuntimeException: A problem occurred while
>> trying to collect debug information about not serializable object
>>
>> Dieter
>>
>> Am 15.06.2016 um 13:39 schrieb Bas Gooren:
>>> Hi Dieter,
>>>
>>> Can you share the stack trace of the serialization checker error?
>>> Normally it points out where in the hierarchy it found a
>>> non-serializable object.
>>> My first guess is that you are referencing the dao class somewhere
>>> directly from your page. The stack trace will prove me right or wrong :-)
>>>
>>> Met vriendelijke groet,
>>> Kind regards,
>>>
>>> Bas Gooren
>>>
>>> Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de
>>> ) schreef:
>>>
 Hello Bas,

 I try to cut small pieces of the code, please tell me if you want to see
 more.

 First the error:

 12:59:03.919 [http-nio-8084-exec-6] WARN
 o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to
 writeObject :

>> de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f,

 path: /children
 12:59:03.925 [http-nio-8084-exec-6] ERROR
 o.a.w.serialize.java.JavaSerializer - Error serializing object class
 de.tremel_computer.abi81.pages.PersonenTable [object=[Page class =
 de.tremel_computer.abi81.pages.PersonenTable, id = 1, render count = 1]]
 org.apache.wicket.WicketRuntimeException: A problem occurred while
 trying to collect debug information about not serializable object
 at

>> org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:278)




 public class PersonenTable extends BasePage {

 @Inject
 private ICachingAbiDataProvider personenProvider;
 ...
 }

 public class AbstractProvider extends
 SortableDataProvider implements IAbiDataProvider {

 @Inject
 private ReadOnlyDao dao;
 ...
 }

 public abstract class JPAReadOnlyDao implements
 ReadOnlyDao {

 private Provider emProvider;
 private final Class entityClass;

 public JPAReadOnlyDao(Class entityClass) {
 this.entityClass = entityClass;
 }
 ...

 @Inject
 public void setEntityManagerProvider(Provider
 emProvider) {
 this.emProvider = emProvider;
 }
 ...
 }

 public class Abi81GuiceModule extends AbstractModule {

 @Override
 protected void configure() {
 bind(PersistServiceInitializer.class).asEagerSingleton();
 bind(new TypeLiteral()
 {}).to(AbiartikelDao.class);
 bind(new TypeLiteral()
 {}).to(PersonenDao.class);
 bind(new TypeLiteral()
 {}).to(PersonenDao.class);
 bind(new TypeLiteral()
 {}).to(CachingAbiartikelProvider.class);
 bind(new TypeLiteral()
 {}).to(CachingPersonenProvider.class);
 }
 }

 BasePage creates a SignInPanel that links to a SignIn-Page, that uses
 methods of SignInSession, that makes use a PersonenDao in only in a
 method.

 I also made a gist:
 https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29

 Thank you
 Dieter


 Am 15.06.2016 um 08:17 schrieb Bas Gooren:
> Dieter,
>
> Since the data provider is inject as a proxy, only the proxy should be
> serialized. On deserialization it should look up the actual data
> provider again.
>
> Can you share some code so we can see how you set things up? What you
> are trying is something that should work out of the box - it does for
> us.
>
> Bas
>
> Verstuurd 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Martin Grigorov]

Hi,

Put a breakpoint at PersonenTable constructor and see what is the type of '
personenProvider'.
It must be JDK Proxy instance.
If it is not then something wrong is going on.

org.apache.wicket.guice.GuiceComponentInjector#GuiceComponentInjector(org.apache.wicket.Application,
com.google.inject.Injector, boolean) - the last parameter here is
'wrapInProxies'. It must be 'true'.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Jun 15, 2016 at 2:18 PM, Dieter Tremel 
wrote:

> Hi Bas,
>
> I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq
>
> I fear it is not really useful, since it starts with
>
> org.apache.wicket.WicketRuntimeException: A problem occurred while
> trying to collect debug information about not serializable object
>
> Dieter
>
> Am 15.06.2016 um 13:39 schrieb Bas Gooren:
> > Hi Dieter,
> >
> > Can you share the stack trace of the serialization checker error?
> > Normally it points out where in the hierarchy it found a
> > non-serializable object.
> > My first guess is that you are referencing the dao class somewhere
> > directly from your page. The stack trace will prove me right or wrong :-)
> >
> > Met vriendelijke groet,
> > Kind regards,
> >
> > Bas Gooren
> >
> > Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de
> > ) schreef:
> >
> >> Hello Bas,
> >>
> >> I try to cut small pieces of the code, please tell me if you want to see
> >> more.
> >>
> >> First the error:
> >>
> >> 12:59:03.919 [http-nio-8084-exec-6] WARN
> >> o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to
> >> writeObject :
> >>
> de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f,
> >>
> >> path: /children
> >> 12:59:03.925 [http-nio-8084-exec-6] ERROR
> >> o.a.w.serialize.java.JavaSerializer - Error serializing object class
> >> de.tremel_computer.abi81.pages.PersonenTable [object=[Page class =
> >> de.tremel_computer.abi81.pages.PersonenTable, id = 1, render count = 1]]
> >> org.apache.wicket.WicketRuntimeException: A problem occurred while
> >> trying to collect debug information about not serializable object
> >> at
> >>
> org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:278)
> >>
> >>
> >>
> >>
> >> public class PersonenTable extends BasePage {
> >>
> >> @Inject
> >> private ICachingAbiDataProvider personenProvider;
> >> ...
> >> }
> >>
> >> public class AbstractProvider extends
> >> SortableDataProvider implements IAbiDataProvider {
> >>
> >> @Inject
> >> private ReadOnlyDao dao;
> >> ...
> >> }
> >>
> >> public abstract class JPAReadOnlyDao implements
> >> ReadOnlyDao {
> >>
> >> private Provider emProvider;
> >> private final Class entityClass;
> >>
> >> public JPAReadOnlyDao(Class entityClass) {
> >> this.entityClass = entityClass;
> >> }
> >> ...
> >>
> >> @Inject
> >> public void setEntityManagerProvider(Provider
> >> emProvider) {
> >> this.emProvider = emProvider;
> >> }
> >> ...
> >> }
> >>
> >> public class Abi81GuiceModule extends AbstractModule {
> >>
> >> @Override
> >> protected void configure() {
> >> bind(PersistServiceInitializer.class).asEagerSingleton();
> >> bind(new TypeLiteral()
> >> {}).to(AbiartikelDao.class);
> >> bind(new TypeLiteral()
> >> {}).to(PersonenDao.class);
> >> bind(new TypeLiteral()
> >> {}).to(PersonenDao.class);
> >> bind(new TypeLiteral()
> >> {}).to(CachingAbiartikelProvider.class);
> >> bind(new TypeLiteral()
> >> {}).to(CachingPersonenProvider.class);
> >> }
> >> }
> >>
> >> BasePage creates a SignInPanel that links to a SignIn-Page, that uses
> >> methods of SignInSession, that makes use a PersonenDao in only in a
> >> method.
> >>
> >> I also made a gist:
> >> https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29
> >>
> >> Thank you
> >> Dieter
> >>
> >>
> >> Am 15.06.2016 um 08:17 schrieb Bas Gooren:
> >> > Dieter,
> >> >
> >> > Since the data provider is inject as a proxy, only the proxy should be
> >> > serialized. On deserialization it should look up the actual data
> >> > provider again.
> >> >
> >> > Can you share some code so we can see how you set things up? What you
> >> > are trying is something that should work out of the box - it does for
> >> > us.
> >> >
> >> > Bas
> >> >
> >> > Verstuurd vanaf mijn iPhone
> >> >
> >> >> Op 15 jun. 2016 om 07:53 heeft Dieter Tremel <
> tre...@tremel-computer.de> het volgende geschreven:
> >> >>
> >> >> Hallo wicket-user,
> >> >>
> >> >> IMHO combining wicket with non serializable objects is a challenging
> topic.
> >> >>
> >> >> On a page I have a DataProvider, that is injected by wicked-guice.
> >> >> Inside this provider an injected dao is used for fetching the data.
> >> >> Inside the dao a provider for a JPA2 entity manager (EclipseLink) is
> >> >> injected.
> >> >>
> 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Dieter Tremel]

Hi Bas,

I put it in http://pastie.org/private/19zeomb8uy1beb1gfjegq

I fear it is not really useful, since it starts with

org.apache.wicket.WicketRuntimeException: A problem occurred while
trying to collect debug information about not serializable object

Dieter

Am 15.06.2016 um 13:39 schrieb Bas Gooren:
> Hi Dieter,
> 
> Can you share the stack trace of the serialization checker error?
> Normally it points out where in the hierarchy it found a
> non-serializable object.
> My first guess is that you are referencing the dao class somewhere
> directly from your page. The stack trace will prove me right or wrong :-)
> 
> Met vriendelijke groet,
> Kind regards,
> 
> Bas Gooren
> 
> Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de
> ) schreef:
> 
>> Hello Bas,
>>
>> I try to cut small pieces of the code, please tell me if you want to see
>> more.
>>
>> First the error:
>>
>> 12:59:03.919 [http-nio-8084-exec-6] WARN
>> o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to
>> writeObject :
>> de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f,
>>
>> path: /children
>> 12:59:03.925 [http-nio-8084-exec-6] ERROR
>> o.a.w.serialize.java.JavaSerializer - Error serializing object class
>> de.tremel_computer.abi81.pages.PersonenTable [object=[Page class =
>> de.tremel_computer.abi81.pages.PersonenTable, id = 1, render count = 1]]
>> org.apache.wicket.WicketRuntimeException: A problem occurred while
>> trying to collect debug information about not serializable object
>> at
>> org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:278)
>>
>>
>>
>>
>> public class PersonenTable extends BasePage {
>>
>> @Inject
>> private ICachingAbiDataProvider personenProvider;
>> ...
>> }
>>
>> public class AbstractProvider extends
>> SortableDataProvider implements IAbiDataProvider {
>>
>> @Inject
>> private ReadOnlyDao dao;
>> ...
>> }
>>
>> public abstract class JPAReadOnlyDao implements
>> ReadOnlyDao {
>>
>> private Provider emProvider;
>> private final Class entityClass;
>>
>> public JPAReadOnlyDao(Class entityClass) {
>> this.entityClass = entityClass;
>> }
>> ...
>>
>> @Inject
>> public void setEntityManagerProvider(Provider
>> emProvider) {
>> this.emProvider = emProvider;
>> }
>> ...
>> }
>>
>> public class Abi81GuiceModule extends AbstractModule {
>>
>> @Override
>> protected void configure() {
>> bind(PersistServiceInitializer.class).asEagerSingleton();
>> bind(new TypeLiteral()
>> {}).to(AbiartikelDao.class);
>> bind(new TypeLiteral()
>> {}).to(PersonenDao.class);
>> bind(new TypeLiteral()
>> {}).to(PersonenDao.class);
>> bind(new TypeLiteral()
>> {}).to(CachingAbiartikelProvider.class);
>> bind(new TypeLiteral()
>> {}).to(CachingPersonenProvider.class);
>> }
>> }
>>
>> BasePage creates a SignInPanel that links to a SignIn-Page, that uses
>> methods of SignInSession, that makes use a PersonenDao in only in a
>> method.
>>
>> I also made a gist:
>> https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29
>>
>> Thank you
>> Dieter
>>
>>
>> Am 15.06.2016 um 08:17 schrieb Bas Gooren:
>> > Dieter,
>> >  
>> > Since the data provider is inject as a proxy, only the proxy should be
>> > serialized. On deserialization it should look up the actual data
>> > provider again.
>> >  
>> > Can you share some code so we can see how you set things up? What you
>> > are trying is something that should work out of the box - it does for
>> > us.
>> >  
>> > Bas
>> >  
>> > Verstuurd vanaf mijn iPhone
>> >  
>> >> Op 15 jun. 2016 om 07:53 heeft Dieter Tremel  
>> >> het volgende geschreven:
>> >>
>> >> Hallo wicket-user,
>> >>
>> >> IMHO combining wicket with non serializable objects is a challenging 
>> >> topic.
>> >>
>> >> On a page I have a DataProvider, that is injected by wicked-guice.
>> >> Inside this provider an injected dao is used for fetching the data.
>> >> Inside the dao a provider for a JPA2 entity manager (EclipseLink) is
>> >> injected.
>> >>
>> >> Page -> DataProvider -> Dao -> Provider
>> >>
>> >> Seems to be useful, but since the page is stateful I recognized the non
>> >> serializeable error for the dao at the end of page rendering.
>> >>
>> >> After some code studies I think wicket-guice is only using a proxy for
>> >> the DataProvider, the second second and third level of injection is done
>> >> only by guice, not handled by wicket-guice and wicket-ioc. This causes
>> >> serializable error for dao. Am I right here? wicket-guice is not as
>> >> useful as it could be, if it would not be restricted to the fields in
>> >> the first level. Setter injection is another topic. The name-pair lets
>> >> associate a transparent combination of the two technologies, but it isn't.
>> >>
>> >> At the moment I have no solution for this.
>> >> I 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Bas Gooren]

Hi Dieter,

Can you share the stack trace of the serialization checker error? Normally it 
points out where in the hierarchy it found a non-serializable object.
My first guess is that you are referencing the dao class somewhere directly 
from your page. The stack trace will prove me right or wrong :-)

Met vriendelijke groet,
Kind regards,

Bas Gooren

Op 15 juni 2016 bij 13:29:24, Dieter Tremel (tre...@tremel-computer.de) schreef:

Hello Bas, 

I try to cut small pieces of the code, please tell me if you want to see 
more. 

First the error: 

12:59:03.919 [http-nio-8084-exec-6] WARN 
o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to 
writeObject : 
de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f, 
path: /children 
12:59:03.925 [http-nio-8084-exec-6] ERROR 
o.a.w.serialize.java.JavaSerializer - Error serializing object class 
de.tremel_computer.abi81.pages.PersonenTable [object=[Page class = 
de.tremel_computer.abi81.pages.PersonenTable, id = 1, render count = 1]] 
org.apache.wicket.WicketRuntimeException: A problem occurred while 
trying to collect debug information about not serializable object 
at 
org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:278)
 



public class PersonenTable extends BasePage { 

@Inject 
private ICachingAbiDataProvider personenProvider; 
... 
} 

public class AbstractProvider extends 
SortableDataProvider implements IAbiDataProvider { 

@Inject 
private ReadOnlyDao dao; 
... 
} 

public abstract class JPAReadOnlyDao implements 
ReadOnlyDao { 

private Provider emProvider; 
private final Class entityClass; 

public JPAReadOnlyDao(Class entityClass) { 
this.entityClass = entityClass; 
} 
... 

@Inject 
public void setEntityManagerProvider(Provider 
emProvider) { 
this.emProvider = emProvider; 
} 
... 
} 

public class Abi81GuiceModule extends AbstractModule { 

@Override 
protected void configure() { 
bind(PersistServiceInitializer.class).asEagerSingleton(); 
bind(new TypeLiteral() 
{}).to(AbiartikelDao.class); 
bind(new TypeLiteral() 
{}).to(PersonenDao.class); 
bind(new TypeLiteral() 
{}).to(PersonenDao.class); 
bind(new TypeLiteral() 
{}).to(CachingAbiartikelProvider.class); 
bind(new TypeLiteral() 
{}).to(CachingPersonenProvider.class); 
} 
} 

BasePage creates a SignInPanel that links to a SignIn-Page, that uses 
methods of SignInSession, that makes use a PersonenDao in only in a method. 

I also made a gist: 
https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29 

Thank you 
Dieter 


Am 15.06.2016 um 08:17 schrieb Bas Gooren: 
> Dieter, 
> 
> Since the data provider is inject as a proxy, only the proxy should be 
> serialized. On deserialization it should look up the actual data 
> provider again. 
> 
> Can you share some code so we can see how you set things up? What you 
> are trying is something that should work out of the box - it does for 
> us. 
> 
> Bas 
> 
> Verstuurd vanaf mijn iPhone 
> 
>> Op 15 jun. 2016 om 07:53 heeft Dieter Tremel  het 
>> volgende geschreven: 
>> 
>> Hallo wicket-user, 
>> 
>> IMHO combining wicket with non serializable objects is a challenging topic. 
>> 
>> On a page I have a DataProvider, that is injected by wicked-guice. 
>> Inside this provider an injected dao is used for fetching the data. 
>> Inside the dao a provider for a JPA2 entity manager (EclipseLink) is 
>> injected. 
>> 
>> Page -> DataProvider -> Dao -> Provider 
>> 
>> Seems to be useful, but since the page is stateful I recognized the non 
>> serializeable error for the dao at the end of page rendering. 
>> 
>> After some code studies I think wicket-guice is only using a proxy for 
>> the DataProvider, the second second and third level of injection is done 
>> only by guice, not handled by wicket-guice and wicket-ioc. This causes 
>> serializable error for dao. Am I right here? wicket-guice is not as 
>> useful as it could be, if it would not be restricted to the fields in 
>> the first level. Setter injection is another topic. The name-pair lets 
>> associate a transparent combination of the two technologies, but it isn't. 
>> 
>> At the moment I have no solution for this. 
>> I still struggle with the right architecture fore using generic JPA2 
>> provided entities on my pages. The only idea so far is not to use guice 
>> and use the application as a link to the non serializable JPA objects 
>> and using detachable models to handle the on pages. 
>> 
>> Any hints for my confused mind welcome. Thanks! 
>> 
>> Dieter Tremel 

- 
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org 
For additional commands, e-mail: users-h...@wicket.apache.org 

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Dieter Tremel]

Hello Bas,

I try to cut small pieces of the code, please tell me if you want to see
more.

First the error:

12:59:03.919 [http-nio-8084-exec-6] WARN
o.a.w.c.u.o.c.CheckingObjectOutputStream - error delegating to
writeObject :
de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f,
path: /children
12:59:03.925 [http-nio-8084-exec-6] ERROR
o.a.w.serialize.java.JavaSerializer - Error serializing object class
de.tremel_computer.abi81.pages.PersonenTable [object=[Page class =
de.tremel_computer.abi81.pages.PersonenTable, id = 1, render count = 1]]
org.apache.wicket.WicketRuntimeException: A problem occurred while
trying to collect debug information about not serializable object
at
org.apache.wicket.serialize.java.JavaSerializer$SerializationCheckerObjectOutputStream.writeObjectOverride(JavaSerializer.java:278)



public class PersonenTable extends BasePage {

@Inject
private ICachingAbiDataProvider personenProvider;
...
}

public class AbstractProvider extends
SortableDataProvider implements IAbiDataProvider {

@Inject
private ReadOnlyDao dao;
...
}

public abstract class JPAReadOnlyDao implements
ReadOnlyDao {

private Provider emProvider;
private final Class entityClass;

public JPAReadOnlyDao(Class entityClass) {
this.entityClass = entityClass;
}
...

@Inject
public void setEntityManagerProvider(Provider
emProvider) {
this.emProvider = emProvider;
}
...
}

public class Abi81GuiceModule extends AbstractModule {

@Override
protected void configure() {
bind(PersistServiceInitializer.class).asEagerSingleton();
bind(new TypeLiteral()
{}).to(AbiartikelDao.class);
bind(new TypeLiteral()
{}).to(PersonenDao.class);
bind(new TypeLiteral()
{}).to(PersonenDao.class);
bind(new TypeLiteral()
{}).to(CachingAbiartikelProvider.class);
bind(new TypeLiteral()
{}).to(CachingPersonenProvider.class);
}
}

BasePage creates a SignInPanel that links to a SignIn-Page, that uses
methods of SignInSession, that makes use a PersonenDao in only in a method.

I also made a gist:
https://gist.github.com/tremel/dd9bfa252282b5853d6d464feccaad29

Thank you
Dieter


Am 15.06.2016 um 08:17 schrieb Bas Gooren:
> Dieter,
> 
> Since the data provider is inject as a proxy, only the proxy should be
> serialized. On deserialization it should look up the actual data
> provider again.
> 
> Can you share some code so we can see how you set things up? What you
> are trying is something that should work out of the box - it does for
> us.
> 
> Bas
> 
> Verstuurd vanaf mijn iPhone
> 
>> Op 15 jun. 2016 om 07:53 heeft Dieter Tremel  het 
>> volgende geschreven:
>>
>> Hallo wicket-user,
>>
>> IMHO combining wicket with non serializable objects is a challenging topic.
>>
>> On a page I have a DataProvider, that is injected by wicked-guice.
>> Inside this provider an injected dao is used for fetching the data.
>> Inside the dao a provider for a JPA2 entity manager (EclipseLink) is
>> injected.
>>
>> Page -> DataProvider -> Dao -> Provider
>>
>> Seems to be useful, but since the page is stateful I recognized the non
>> serializeable error for the dao at the end of page rendering.
>>
>> After some code studies I think wicket-guice is only using a proxy for
>> the DataProvider, the second second and third level of injection is done
>> only by guice, not handled by wicket-guice and wicket-ioc. This causes
>> serializable error for dao. Am I right here? wicket-guice is not as
>> useful as it could be, if it would not be restricted to the fields in
>> the first level. Setter injection is another topic. The name-pair lets
>> associate a transparent combination of the two technologies, but it isn't.
>>
>> At the moment I have no solution for this.
>> I still struggle with the right architecture fore using generic JPA2
>> provided entities on my pages. The only idea so far is not to use guice
>> and use the application as a link to the non serializable JPA objects
>> and using detachable models to handle the on pages.
>>
>> Any hints for my confused mind welcome. Thanks!
>>
>> Dieter Tremel

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: wicket-guice and recursive injection of non serializable JPA2 objects

[Bas Gooren]

Dieter,

Since the data provider is inject as a proxy, only the proxy should be
serialized. On deserialization it should look up the actual data
provider again.

Can you share some code so we can see how you set things up? What you
are trying is something that should work out of the box - it does for
us.

Bas

Verstuurd vanaf mijn iPhone

> Op 15 jun. 2016 om 07:53 heeft Dieter Tremel  het 
> volgende geschreven:
>
> Hallo wicket-user,
>
> IMHO combining wicket with non serializable objects is a challenging topic.
>
> On a page I have a DataProvider, that is injected by wicked-guice.
> Inside this provider an injected dao is used for fetching the data.
> Inside the dao a provider for a JPA2 entity manager (EclipseLink) is
> injected.
>
> Page -> DataProvider -> Dao -> Provider
>
> Seems to be useful, but since the page is stateful I recognized the non
> serializeable error for the dao at the end of page rendering.
>
> After some code studies I think wicket-guice is only using a proxy for
> the DataProvider, the second second and third level of injection is done
> only by guice, not handled by wicket-guice and wicket-ioc. This causes
> serializable error for dao. Am I right here? wicket-guice is not as
> useful as it could be, if it would not be restricted to the fields in
> the first level. Setter injection is another topic. The name-pair lets
> associate a transparent combination of the two technologies, but it isn't.
>
> At the moment I have no solution for this.
> I still struggle with the right architecture fore using generic JPA2
> provided entities on my pages. The only idea so far is not to use guice
> and use the application as a link to the non serializable JPA objects
> and using detachable models to handle the on pages.
>
> Any hints for my confused mind welcome. Thanks!
>
> Dieter Tremel
>
> -
> 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