date:20160617

Re: Problem migrating to Wicket 7

2016-06-17 Thread Martin Grigorov

It is caused by a change for WICKET-5988

Now the body container is not added to the Border but it relies solely on
component resolving.
The problem is that the resolving is not used when visiting the children

Please file a ticket at JIRA!
Thanks!
On Jun 17, 2016 10:08 AM, "Martin Grigorov"  wrote:

> Hi,
>
> I'll take a look soon!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Jun 16, 2016 at 8:04 AM, Dirk Forchel 
> wrote:
>
>> Hi Martin,
>> I've added a much more simpler test application to show what's not working
>> (see myproject2.zip below).
>> On the first page you can see on the right side a TextComponent with a
>> simple Behavior added to a Page. This Behavior adds some
>> JavaScriptResourceReference (the jQuery function definition) and an
>> OnDomReadyHeaderItem (the jQuery function call) to the header. If it
>> works,
>> the value of the input field is replaced from "test" to "Hello Dude!" and
>> the input element is highlighted for a short moment.
>> On the second page you can find the same functionality but added to a
>> Border
>> component. This works as well as described.
>> On the third page I've added a TextComponent with the same Behavior but to
>> the BorderBodyContainer (the content area) of our layout class (a Border
>> component) which is added to another Border (our layout container). On
>> this
>> page, the Behavior is NOT working with Wicket 7.3. But the same IS working
>> with Wicket 6.23. You can easily switch between both versions by changing
>> the wicket.version in the pom.xml.
>> I've noticed during my investigation, that the "renderHead" method of the
>> Behavior class never gets called and I have not glue why! I could imagine,
>> that one reason could be the fact, that we use two nested Border
>> components.
>> But the behavior should work with this combination as well, I think.
>> Could you please have a look at this problem.
>>
>> Here is the quickstart:  myproject2.zip
>> 
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/Problem-migrating-to-Wicket-7-tp4674842p4674910.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
>>
>>
>

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

2016-06-17 Thread 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

2016-06-17 Thread 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 instance.
> > If it is not

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

2016-06-17 Thread 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 collect debug information a

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

2016-06-17 Thread 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
 ) schreef:

> Hello Bas,

Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-06-17 Thread Fabio Fioretti

Thanks Martin,

This is good news. Looking forward to 6.24.0.

Kind regards,
Fabio

On Fri, Jun 17, 2016 at 10:26 AM, Martin Grigorov 
wrote:

> Hi Fabio,
>
> I agree that the removal of the default message is not really needed.
> It has been done with https://issues.apache.org/jira/browse/WICKET-5735.
>
> I've reverted this with https://issues.apache.org/jira/browse/WICKET-6181
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Jun 13, 2016 at 1:43 PM, Fabio Fioretti <
> windom.macroso...@gmail.com
> > wrote:
>
> > Hi all,
> > Does anybody have any feedback on this?
> >
> > Many thanks,
> > Fabio
> >
> > On Tue, May 31, 2016 at 12:46 PM, Fabio Fioretti <
> > windom.macroso...@gmail.com> wrote:
> >
> > > Hi Martin,
> > >
> > > You are right, the form id was already there in 6.17.0, but the default
> > > message was removed! That is what is breaking my app - I did not
> realize
> > it
> > > because my custom message was the same as the default.
> > >
> > > Why was it removed?
> > >
> > > In 6.17.0:
> > > final String defaultValue = "Upload must be less than " + getMaxSize();
> > > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> > > Model.ofMap(model), defaultValue)
> > >
> > > While in 6.23.0:
> > > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> > > Model.ofMap(model));
> > >
> > > Interestingly, the comment still says "Resource key should be
> > > .uploadTooLarge to override default message".
> > >
> > > IMHO, forcing to have the root (!) form id in the property key makes it
> > > impossible to create a reusable component for managing uploads, like an
> > > UploadPanel with its own form and FileUploadField . In fact, as soon as
> > you
> > > place it in a hierarchy that includes an outer form, it will break your
> > > app. The default value at least provided a safe fallback.
> > >
> > > What do you think?
> > >
> > > Many thanks,
> > > Fabio
> > >
> > >
> > > On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov  >
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti <
> > >> windom.macroso...@gmail.com> wrote:
> > >>
> > >> > Hi Martin,
> > >> >
> > >> > Is this the ticket you refer to?
> > >> > https://issues.apache.org/jira/browse/WICKET-5190
> > >>
> > >>
> > >> Yes, this is the one!
> > >>
> > >>
> > >> >
> > >> >
> > >> > It has an explanation on why onFileUploadException() is called on
> the
> > >> root
> > >> > form that seems reasonable.
> > >> >
> > >> > In any case, if I don't specify the form id in the property key
> > (leaving
> > >> > just "uploadTooLarge") I get the following MissingResourceException
> > when
> > >> > FileUploadBase.SizeLimitExceededException is thrown:
> > >> >
> > >>
> > >> According to Git history the id was there even in 6.17:
> > >>
> > >>
> >
> https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423
> > >>
> > >> The id is not in Wicket 7.x though!
> > >> It has been removed with
> > >> https://issues.apache.org/jira/browse/WICKET-5206
> > >> 3 years ago
> > >>
> > >>
> > >> >
> > >> > *java.util.MissingResourceException*: Unable to find property:
> > >> > 'form1.uploadTooLarge' for component: border:border_body:form1
> > >> > [class=org.apache.wicket.markup.html.form.Form].
> > >> > Locale: null, style: null
> > >> >
> > >> > As you can see, I do have a border complicating things (not sure if
> it
> > >> > might play a role here) but it worked just fine in Wicket 6.17.0. In
> > >> fact I
> > >> > had to add the form id ("form0.uploadTooLarge") to make it work in
> > >> 6.23.0,
> > >> > but then I ran into this other issue that, when form0 is nested in
> > >> > form1, Wicket looks up for "form1.uploadTooLarge" instead.
> > >> >
> > >> > I also noticed that there is a new fileMaxSize property in Form that
> > >> wasn't
> > >> > there in 6.17.0. Should I use that one instead of maxSize? It has no
> > >> setter
> > >> > though...
> > >> >
> > >>
> > >> This is related to https://issues.apache.org/jira/browse/WICKET-5735
> > >>
> > >>
> > >> >
> > >> > Any clarification would be much appreciated.
> > >> >
> > >> > Many thanks,
> > >> > Fabio
> > >> >
> > >> > On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <
> > mgrigo...@apache.org>
> > >> > wrote:
> > >> >
> > >> > > Hi,
> > >> > >
> > >> > > I believe there is/was another ticket describing exactly your
> > problem
> > >> > but I
> > >> > > cannot find it now.
> > >> > >
> > >> > > The form id in the property key is not really needed.
> > >> > > You could use it to give Wicket a more specific message for
> > particular
> > >> > > component.
> > >> > > You can remove it if this message should/could be used for any
> other
> > >> Form
> > >> > > in you application/package/page/panel (depending in which
> > .properties
> > >> > file
> > >> > > you have it).
> > >> > >
> > >> > > Martin Grigorov
> > >> > > Wicket Training

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

2016-06-17 Thread 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 :-)
> >> >>>
> >> >>> Met vri

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

2016-06-17 Thread 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 :
>> 
>> >> de.tremel_computer.abi81.datahandling.PersonenDao$$EnhancerByGuice$$4769627f,

Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

2016-06-17 Thread Martin Grigorov

Hi Fabio,

I agree that the removal of the default message is not really needed.
It has been done with https://issues.apache.org/jira/browse/WICKET-5735.

I've reverted this with https://issues.apache.org/jira/browse/WICKET-6181


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

On Mon, Jun 13, 2016 at 1:43 PM, Fabio Fioretti  wrote:

> Hi all,
> Does anybody have any feedback on this?
>
> Many thanks,
> Fabio
>
> On Tue, May 31, 2016 at 12:46 PM, Fabio Fioretti <
> windom.macroso...@gmail.com> wrote:
>
> > Hi Martin,
> >
> > You are right, the form id was already there in 6.17.0, but the default
> > message was removed! That is what is breaking my app - I did not realize
> it
> > because my custom message was the same as the default.
> >
> > Why was it removed?
> >
> > In 6.17.0:
> > final String defaultValue = "Upload must be less than " + getMaxSize();
> > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> > Model.ofMap(model), defaultValue)
> >
> > While in 6.23.0:
> > String msg = getString(getId() + '.' + UPLOAD_TOO_LARGE_RESOURCE_KEY,
> > Model.ofMap(model));
> >
> > Interestingly, the comment still says "Resource key should be
> > .uploadTooLarge to override default message".
> >
> > IMHO, forcing to have the root (!) form id in the property key makes it
> > impossible to create a reusable component for managing uploads, like an
> > UploadPanel with its own form and FileUploadField . In fact, as soon as
> you
> > place it in a hierarchy that includes an outer form, it will break your
> > app. The default value at least provided a safe fallback.
> >
> > What do you think?
> >
> > Many thanks,
> > Fabio
> >
> >
> > On Mon, May 30, 2016 at 4:31 PM, Martin Grigorov 
> > wrote:
> >
> >> Hi,
> >>
> >> On Fri, May 27, 2016 at 12:42 PM, Fabio Fioretti <
> >> windom.macroso...@gmail.com> wrote:
> >>
> >> > Hi Martin,
> >> >
> >> > Is this the ticket you refer to?
> >> > https://issues.apache.org/jira/browse/WICKET-5190
> >>
> >>
> >> Yes, this is the one!
> >>
> >>
> >> >
> >> >
> >> > It has an explanation on why onFileUploadException() is called on the
> >> root
> >> > form that seems reasonable.
> >> >
> >> > In any case, if I don't specify the form id in the property key
> (leaving
> >> > just "uploadTooLarge") I get the following MissingResourceException
> when
> >> > FileUploadBase.SizeLimitExceededException is thrown:
> >> >
> >>
> >> According to Git history the id was there even in 6.17:
> >>
> >>
> https://github.com/apache/wicket/blob/wicket-6.17.0/wicket-core/src/main/java/org/apache/wicket/markup/html/form/Form.java#L1423
> >>
> >> The id is not in Wicket 7.x though!
> >> It has been removed with
> >> https://issues.apache.org/jira/browse/WICKET-5206
> >> 3 years ago
> >>
> >>
> >> >
> >> > *java.util.MissingResourceException*: Unable to find property:
> >> > 'form1.uploadTooLarge' for component: border:border_body:form1
> >> > [class=org.apache.wicket.markup.html.form.Form].
> >> > Locale: null, style: null
> >> >
> >> > As you can see, I do have a border complicating things (not sure if it
> >> > might play a role here) but it worked just fine in Wicket 6.17.0. In
> >> fact I
> >> > had to add the form id ("form0.uploadTooLarge") to make it work in
> >> 6.23.0,
> >> > but then I ran into this other issue that, when form0 is nested in
> >> > form1, Wicket looks up for "form1.uploadTooLarge" instead.
> >> >
> >> > I also noticed that there is a new fileMaxSize property in Form that
> >> wasn't
> >> > there in 6.17.0. Should I use that one instead of maxSize? It has no
> >> setter
> >> > though...
> >> >
> >>
> >> This is related to https://issues.apache.org/jira/browse/WICKET-5735
> >>
> >>
> >> >
> >> > Any clarification would be much appreciated.
> >> >
> >> > Many thanks,
> >> > Fabio
> >> >
> >> > On Thu, May 26, 2016 at 7:18 PM, Martin Grigorov <
> mgrigo...@apache.org>
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I believe there is/was another ticket describing exactly your
> problem
> >> > but I
> >> > > cannot find it now.
> >> > >
> >> > > The form id in the property key is not really needed.
> >> > > You could use it to give Wicket a more specific message for
> particular
> >> > > component.
> >> > > You can remove it if this message should/could be used for any other
> >> Form
> >> > > in you application/package/page/panel (depending in which
> .properties
> >> > file
> >> > > you have it).
> >> > >
> >> > > Martin Grigorov
> >> > > Wicket Training and Consulting
> >> > > https://twitter.com/mtgrigorov
> >> > >
> >> > > On Thu, May 26, 2016 at 6:46 PM, Fabio Fioretti <
> >> > > windom.macroso...@gmail.com
> >> > > > wrote:
> >> > >
> >> > > > Hello everybody,
> >> > > >
> >> > > > I recently migrated an application from Wicket 6.17.0 to 6.23.0
> and
> >> I'm
> >> > > > experiencing the following problem.
> >> > > >
> >> > > > I have 2 nested forms. The inner one, form0, contains a
> >> FileUploadField
> >> > > > with an AjaxFo

Re: Problem migrating to Wicket 7

2016-06-17 Thread Martin Grigorov

Hi,

I'll take a look soon!

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

On Thu, Jun 16, 2016 at 8:04 AM, Dirk Forchel 
wrote:

> Hi Martin,
> I've added a much more simpler test application to show what's not working
> (see myproject2.zip below).
> On the first page you can see on the right side a TextComponent with a
> simple Behavior added to a Page. This Behavior adds some
> JavaScriptResourceReference (the jQuery function definition) and an
> OnDomReadyHeaderItem (the jQuery function call) to the header. If it works,
> the value of the input field is replaced from "test" to "Hello Dude!" and
> the input element is highlighted for a short moment.
> On the second page you can find the same functionality but added to a
> Border
> component. This works as well as described.
> On the third page I've added a TextComponent with the same Behavior but to
> the BorderBodyContainer (the content area) of our layout class (a Border
> component) which is added to another Border (our layout container). On this
> page, the Behavior is NOT working with Wicket 7.3. But the same IS working
> with Wicket 6.23. You can easily switch between both versions by changing
> the wicket.version in the pom.xml.
> I've noticed during my investigation, that the "renderHead" method of the
> Behavior class never gets called and I have not glue why! I could imagine,
> that one reason could be the fact, that we use two nested Border
> components.
> But the behavior should work with this combination as well, I think.
> Could you please have a look at this problem.
>
> Here is the quickstart:  myproject2.zip
> 
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Problem-migrating-to-Wicket-7-tp4674842p4674910.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
>
>

Re: Problem migrating to Wicket 7

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

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

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

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

Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

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

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

Re: AjaxFormSubmitBehavior, FileUploadField and nested forms.

Re: Problem migrating to Wicket 7

10 matches

Site Navigation

Mail list logo

Footer information