WebResource in Wicket 1.5

[nazeem]

I have a open flash chart implementation following the link below.

https://cwiki.apache.org/WICKET/open-flash-chart-and-wicket.html

But when i upgrade to wicket 1.5 im stuck at this..

In class OpenFlashChart, 

 WebResource jsonResource = new WebResource() {
  @Override
  public IResourceStream getResourceStream() {
return json;
  }
};
jsonResource.setCacheable(false);

 ...

public void onResourceRequested() {
jsonResource.onResourceRequested();
  }



 
What is the replacement for this in wicket 1.5 ? 



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/WebResource-in-Wicket-1-5-tp4106181p4106181.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: There are problems with

[andreyich]

And if it possible could you answer on another question!

What I did wrong?



Java
JRResource pdfResource = new
JRConcreteResource(reportFile,
new PdfResourceHandler()).setReportDataSource(new
JRBeanCollectionDataSource(historyReports));
EmbeddedJRReport jrReport = new EmbeddedJRReport("report", pdfResource) ;
add(jrReport);

*Html*



*This is the example for jasperreports-examples for show pdf on the page!
But Pdf dont show in the page.*

But if I try to do example with Report link I am getting pdf 

*Java*
JRResource pdfResource = new
JRConcreteResource(reportFile,
new
PdfResourceHandler()).setReportParameters(parameters).setReportDataSource(new
JRBeanCollectionDataSource(historyReports));
add(new ResourceLink("linkToPdf", pdfResource));

*Html*
# display PDF report 

What problems here ?  

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/There-are-problems-with-object-wicket-id-report-width-350-height-100-tp4099376p4105762.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: There are problems with

[andreyich]

And if it possible could you answer on another question!

What I did wrong?



Java
JRResource pdfResource = new
JRConcreteResource(reportFile,
new PdfResourceHandler()).setReportDataSource(new
JRBeanCollectionDataSource(historyReports));
EmbeddedJRReport jrReport = new EmbeddedJRReport("report", pdfResource) ;
add(jrReport);

*Html*




*This is the example for jasperreports-examples for show pdf on the page!
But Pdf dont show in the page.*

But if I try to do example with Report link I am getting pdf 

*Java*
JRResource pdfResource = new
JRConcreteResource(reportFile,
new
PdfResourceHandler()).setReportParameters(parameters).setReportDataSource(new
JRBeanCollectionDataSource(historyReports));
add(new ResourceLink("linkToPdf", pdfResource));

*Html*
# display PDF report 

What problems here ?  

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/There-are-problems-with-object-wicket-id-report-width-350-height-100-tp4099376p4105753.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-cdi NotSerializableException for injected SLSB proxy

[Phill]

https://github.com/42Lines/wicket-cdi/issues/14

On 24/nov/2011, at 17:19, Igor Vaynberg wrote:

> btw, feel free to open an issue in wicket-cdi
> 
> -igor
> 
> On Thu, Nov 24, 2011 at 4:03 AM, Phill  wrote:
>> On further investigation it doesn't seem to be a weld/glassfish bug as as 
>> far as I can tell there is no requirement for a Stateless EJB proxy to be 
>> serializable.
>> The issue was raised here where a patch to seam-wicket was proposed:
>> https://issues.jboss.org/browse/SEAMWICKET-41
>> Any chance of a similar workaround for wicket-cdi?
>> 
>> Interestingly if I inject the @Stateless EJB into an @ApplicationScoped bean 
>> and then inject the application scoped bean into my page there are no 
>> serialization issues, suggesting that in this case the proxy for the SLSB is 
>> serializable.
>> -Phill
>> 
>> 
>> On 16/nov/2011, at 17:24, Igor Vaynberg wrote:
>> 
>>> looks like a weld/glassfish bug, especially since other kinds of proxies
>>> (even for application-scoped objects) are serializable.
>>> 
>>> -igor
>>> 
>>> On Wed, Nov 16, 2011 at 12:52 AM, Phill  wrote:
>>> 
 I'm using the wicket-cdi module (https://github.com/42Lines/wicket-cdi)
 to inject an SLSB with Glassfish 3.1.1
 
 MyWebApplication.init()
 
 BeanManager  manager = (BeanManager) ic.lookup("java:comp/BeanManager");
 new CdiConfiguration(manager)
   .setPropagation(ConversationPropagation.NONBOOKMARKABLE)
   .configure(this);
 
 public class DashboardPage extends AuthorisedBasePage {
   @Inject
   private AccountingService accountingService;
 …
 }
 
 Injection is working fine and I can use the session bean but Wicket is
 unable to serialize the proxy.
 According to my research previous issues with the Weld proxy not being
 serializable should have been resolved in the version that shipped with GF
 3.1.
 I've also tried the latest GF 3.1.2 promoted build which uses Weld 1.1.3
 and I get the same problem.
 
 I'm not really sure if this is a Wicket issue or whether I should be
 taking it up with the Weld team.. any pointers appreciated.
 
 
 2011-11-16 09:05:17,201 [http-thread-pool-8181(4)] ERROR
 org.apache.wicket.serialize.java.JavaSerializer - Error serializing object
 class uk.co.leadseeker.webapp.user.DashboardPage [object=[Page class =
 uk.co.leadseeker.webapp.user.DashboardPage, id = 3, render count = 1]]
 java.io.NotSerializableException
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


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

Re: AjaxSelfUpdatingTimerBehavior stops working for a while

[Ramona]

Hi! Thanks for your answer.
I tried that and set 200 as value but it still happens the same.
Any other idea?



Martin Grigorov-4 wrote
> 
> Hi
> 
> Try with Firefox and see at how many connections it stops working.
> The open "about:config" page and change the value of
> "network.http.max-connections-per-server" setting and try again.
> 
> On Thu, Nov 24, 2011 at 12:46 AM, Ramona  wrote:
>> Hi all!
>> I'm using AjaxSelfUpdatingTimerBehavior for updating some progress bars
>> with
>> multiple file uploads (it's simulated with a Servlet), but when i try to
>> upload for example 8 files the behaviour (which has been working and
>> listening) stops listening for a while (the uploading continues but the
>> listener isn't called , this listener is used for updating some panels
>> with
>> files uploading information).
>> Any idea? Why could a AjaxSelfUpdatingTimerBehavior stops working for a
>> while? ..beacause after for example 3 minutes it restarts (i have it as:
>> refreshComponent.add(behavior= new
>> AjaxSelfUpdatingTimerBehavior(Duration.milliseconds(1000)) ).
>>
>> Thanks!
>>
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/AjaxSelfUpdatingTimerBehavior-stops-working-for-a-while-tp4101950p4101950.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>>
>>
> 
> 
> 
> -- 
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
> 
> -
> To unsubscribe, e-mail: users-unsubscribe@.apache
> For additional commands, e-mail: users-help@.apache
> 


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/AjaxSelfUpdatingTimerBehavior-stops-working-for-a-while-tp4101950p4105320.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: AjaxSelfUpdatingTimerBehavior stops working for a while

[Ramona]

Hi Dan! 
It's just one behavior and Wicket Ajax window doesn't show any error log.
It first starts the behavior like this:

INFO: Response parsed. Now invoking steps...
INFO: Response processed successfully.
INFO: Invoking post-call handler(s)...
INFO: refocus last focused component not needed/allowed
INFO:
INFO: Initiating Ajax GET request on
?wicket:interface=:15:upload_component:upload:list_and_refresh:refresh-panel::IActivePageBehaviorListener:0:
-1&wicket:ignoreIfNotActive=true&random=0.2869209546584387
INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (1627 characters)
INFO:


but when i upload many files it stops sending responses, like this:

INFO: Response parsed. Now invoking steps...
INFO: Response processed successfully.
INFO: Invoking post-call handler(s)...
INFO: refocus last focused component not needed/allowed
INFO:
INFO: Initiating Ajax GET request on
?wicket:interface=:15:upload_component:upload:list_and_refresh:refresh-panel::IActivePageBehaviorListener:0:
-1&wicket:ignoreIfNotActive=true&random=0.49126573698542464
INFO: Invoking pre-call handler(s).


Dan Retzlaff wrote
> 
> Hi Ramona,
> 
> Is this one Ajax behavior or many (8)? Does the Wicket AJAX window in your
> browser show anything interesting? In particular I would look for "channel
> busy" messages, indicating that some other AJAX request is pending when a
> new one is triggered.
> 
> Dan
> 
> On Wed, Nov 23, 2011 at 2:46 PM, Ramona  wrote:
> 
>> Hi all!
>> I'm using AjaxSelfUpdatingTimerBehavior for updating some progress bars
>> with
>> multiple file uploads (it's simulated with a Servlet), but when i try to
>> upload for example 8 files the behaviour (which has been working and
>> listening) stops listening for a while (the uploading continues but the
>> listener isn't called , this listener is used for updating some panels
>> with
>> files uploading information).
>> Any idea? Why could a AjaxSelfUpdatingTimerBehavior stops working for a
>> while? ..beacause after for example 3 minutes it restarts (i have it as:
>> refreshComponent.add(behavior= new
>> AjaxSelfUpdatingTimerBehavior(Duration.milliseconds(1000)) ).
>>
>> Thanks!
>>
>>
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/AjaxSelfUpdatingTimerBehavior-stops-working-for-a-while-tp4101950p4101950.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscribe@.apache
>> For additional commands, e-mail: users-help@.apache
>>
>>
> 


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/AjaxSelfUpdatingTimerBehavior-stops-working-for-a-while-tp4101950p4105312.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: Forms marked as multipart do not work with ajax and IE9

[Stijn Maller]

Sorry to come back to this old issue, but we are struggling with it too and
unfortunately the solutions mentioned do not seem to work for us. Our app
already specified the doctype for html 4, and I also tried the html 5
doctype after reading your mails, but to no avail.

Our page is being rendered in standards mode ok, but when the ajax response
is received IE suddenly decides to switch to quirks mode. It spits out the
following message to the console: *HTML1113*: *Document mode restart from
IE9 Standards to Quirks*. I have no clue why it decides to do this nor how
I can prevent it. Anyone able to shed some light onto this?

This is more then annoying, because it means that our app becomes
completely useless on IE9.

Kind regards,
Stijn


Unfortunately our app already had the html 4 doctype declaration and was
already being rendered in

On 6 May 2011 12:42, Wayne W  wrote:

> Hi,
>
> We have a form that you can make comments in against something. This
> is submitted normally via a AjaxSubmitLink, however if you attach a
> file to the form then then form is submitted in a normal non-ajax
> request.
> The problem I'm seeing is if a form is marked as multipart/form-data
> then is submited via ajax IE9 fails with :
>
> Wicket.Ajax.Call.failure: Error while parsing response: Could not find
> root 
>
> IE8 and 7 work fine. Doing some debugging in IE9 versus FF I see that
> in handleMultipartComplete() that the envelope is of type
> DispHTMLDocument instead of XMLDocument
>
> I'm now trying to work around the problem by removing the enctype
> attribute if doing an ajax request.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: wicket-cdi NotSerializableException for injected SLSB proxy

[Igor Vaynberg]

btw, feel free to open an issue in wicket-cdi

-igor

On Thu, Nov 24, 2011 at 4:03 AM, Phill  wrote:
> On further investigation it doesn't seem to be a weld/glassfish bug as as far 
> as I can tell there is no requirement for a Stateless EJB proxy to be 
> serializable.
> The issue was raised here where a patch to seam-wicket was proposed:
> https://issues.jboss.org/browse/SEAMWICKET-41
> Any chance of a similar workaround for wicket-cdi?
>
> Interestingly if I inject the @Stateless EJB into an @ApplicationScoped bean 
> and then inject the application scoped bean into my page there are no 
> serialization issues, suggesting that in this case the proxy for the SLSB is 
> serializable.
> -Phill
>
>
> On 16/nov/2011, at 17:24, Igor Vaynberg wrote:
>
>> looks like a weld/glassfish bug, especially since other kinds of proxies
>> (even for application-scoped objects) are serializable.
>>
>> -igor
>>
>> On Wed, Nov 16, 2011 at 12:52 AM, Phill  wrote:
>>
>>> I'm using the wicket-cdi module (https://github.com/42Lines/wicket-cdi)
>>> to inject an SLSB with Glassfish 3.1.1
>>>
>>> MyWebApplication.init()
>>>
>>> BeanManager  manager = (BeanManager) ic.lookup("java:comp/BeanManager");
>>> new CdiConfiguration(manager)
>>>       .setPropagation(ConversationPropagation.NONBOOKMARKABLE)
>>>       .configure(this);
>>>
>>> public class DashboardPage extends AuthorisedBasePage {
>>>   @Inject
>>>   private AccountingService accountingService;
>>> …
>>> }
>>>
>>> Injection is working fine and I can use the session bean but Wicket is
>>> unable to serialize the proxy.
>>> According to my research previous issues with the Weld proxy not being
>>> serializable should have been resolved in the version that shipped with GF
>>> 3.1.
>>> I've also tried the latest GF 3.1.2 promoted build which uses Weld 1.1.3
>>> and I get the same problem.
>>>
>>> I'm not really sure if this is a Wicket issue or whether I should be
>>> taking it up with the Weld team.. any pointers appreciated.
>>>
>>>
>>> 2011-11-16 09:05:17,201 [http-thread-pool-8181(4)] ERROR
>>> org.apache.wicket.serialize.java.JavaSerializer - Error serializing object
>>> class uk.co.leadseeker.webapp.user.DashboardPage [object=[Page class =
>>> uk.co.leadseeker.webapp.user.DashboardPage, id = 3, render count = 1]]
>>> java.io.NotSerializableException
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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

Re: wicket-cdi NotSerializableException for injected SLSB proxy

[Igor Vaynberg]

On Thu, Nov 24, 2011 at 4:03 AM, Phill  wrote:
> On further investigation it doesn't seem to be a weld/glassfish bug as as far 
> as I can tell there is no requirement for a Stateless EJB proxy to be 
> serializable.
> The issue was raised here where a patch to seam-wicket was proposed:
> https://issues.jboss.org/browse/SEAMWICKET-41
> Any chance of a similar workaround for wicket-cdi?

i will take a look...

> Interestingly if I inject the @Stateless EJB into an @ApplicationScoped bean 
> and then inject the application scoped bean into my page there are no 
> serialization issues, suggesting that in this case the proxy for the SLSB is 
> serializable.

no. the proxy to the application scoped bean is serializable so the
proxy to the slsb is never serialized. this might be a way to go,
creating applicationscoped wrappers for your slsbs...

-igor

> -Phill
>
>
> On 16/nov/2011, at 17:24, Igor Vaynberg wrote:
>
>> looks like a weld/glassfish bug, especially since other kinds of proxies
>> (even for application-scoped objects) are serializable.
>>
>> -igor
>>
>> On Wed, Nov 16, 2011 at 12:52 AM, Phill  wrote:
>>
>>> I'm using the wicket-cdi module (https://github.com/42Lines/wicket-cdi)
>>> to inject an SLSB with Glassfish 3.1.1
>>>
>>> MyWebApplication.init()
>>>
>>> BeanManager  manager = (BeanManager) ic.lookup("java:comp/BeanManager");
>>> new CdiConfiguration(manager)
>>>       .setPropagation(ConversationPropagation.NONBOOKMARKABLE)
>>>       .configure(this);
>>>
>>> public class DashboardPage extends AuthorisedBasePage {
>>>   @Inject
>>>   private AccountingService accountingService;
>>> …
>>> }
>>>
>>> Injection is working fine and I can use the session bean but Wicket is
>>> unable to serialize the proxy.
>>> According to my research previous issues with the Weld proxy not being
>>> serializable should have been resolved in the version that shipped with GF
>>> 3.1.
>>> I've also tried the latest GF 3.1.2 promoted build which uses Weld 1.1.3
>>> and I get the same problem.
>>>
>>> I'm not really sure if this is a Wicket issue or whether I should be
>>> taking it up with the Weld team.. any pointers appreciated.
>>>
>>>
>>> 2011-11-16 09:05:17,201 [http-thread-pool-8181(4)] ERROR
>>> org.apache.wicket.serialize.java.JavaSerializer - Error serializing object
>>> class uk.co.leadseeker.webapp.user.DashboardPage [object=[Page class =
>>> uk.co.leadseeker.webapp.user.DashboardPage, id = 3, render count = 1]]
>>> java.io.NotSerializableException
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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

Re: There are problems with

[andreyich]

Thank you! i see   

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/There-are-problems-with-object-wicket-id-report-width-350-height-100-tp4099376p4103718.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-cdi NotSerializableException for injected SLSB proxy

[Phill]

On further investigation it doesn't seem to be a weld/glassfish bug as as far 
as I can tell there is no requirement for a Stateless EJB proxy to be 
serializable.
The issue was raised here where a patch to seam-wicket was proposed:
https://issues.jboss.org/browse/SEAMWICKET-41
Any chance of a similar workaround for wicket-cdi? 

Interestingly if I inject the @Stateless EJB into an @ApplicationScoped bean 
and then inject the application scoped bean into my page there are no 
serialization issues, suggesting that in this case the proxy for the SLSB is 
serializable.
-Phill


On 16/nov/2011, at 17:24, Igor Vaynberg wrote:

> looks like a weld/glassfish bug, especially since other kinds of proxies
> (even for application-scoped objects) are serializable.
> 
> -igor
> 
> On Wed, Nov 16, 2011 at 12:52 AM, Phill  wrote:
> 
>> I'm using the wicket-cdi module (https://github.com/42Lines/wicket-cdi)
>> to inject an SLSB with Glassfish 3.1.1
>> 
>> MyWebApplication.init()
>> 
>> BeanManager  manager = (BeanManager) ic.lookup("java:comp/BeanManager");
>> new CdiConfiguration(manager)
>>   .setPropagation(ConversationPropagation.NONBOOKMARKABLE)
>>   .configure(this);
>> 
>> public class DashboardPage extends AuthorisedBasePage {
>>   @Inject
>>   private AccountingService accountingService;
>> …
>> }
>> 
>> Injection is working fine and I can use the session bean but Wicket is
>> unable to serialize the proxy.
>> According to my research previous issues with the Weld proxy not being
>> serializable should have been resolved in the version that shipped with GF
>> 3.1.
>> I've also tried the latest GF 3.1.2 promoted build which uses Weld 1.1.3
>> and I get the same problem.
>> 
>> I'm not really sure if this is a Wicket issue or whether I should be
>> taking it up with the Weld team.. any pointers appreciated.
>> 
>> 
>> 2011-11-16 09:05:17,201 [http-thread-pool-8181(4)] ERROR
>> org.apache.wicket.serialize.java.JavaSerializer - Error serializing object
>> class uk.co.leadseeker.webapp.user.DashboardPage [object=[Page class =
>> uk.co.leadseeker.webapp.user.DashboardPage, id = 3, render count = 1]]
>> java.io.NotSerializableException

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

Re: add resources to javascript

[Philipp Schreiber]

So.. ok nevermind... just mounted the resources as PackageResourceReference
and used it in JS 

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/add-resources-to-javascript-tp4101004p4103562.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: Button with 3 images and issues

[D0m3]

Ok eventually I have made a behavior which extends
AbstractTransformerBehavior, because I wanted to add the markup to Link,
Button, AjaxButton, etc.
About the disabled part, I check in the behavior whether the component is
enabled and I add Disabled to my classes if not.
Don't hesitate if you have comments.
At least I hope it can help someone.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Button-with-3-images-and-issues-tp4082830p4103246.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: Putting together two seperate wicket projects into a multi-module maven project

[nivs]

Hi

Sometime back I did something similar. The thread is here see if this helps.

http://apache-wicket.1842946.n4.nabble.com/Re-Using-Wicket-to-build-Application-Portal-td2248912.html#a2258389
Multiple Mave Projects 

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Putting-together-two-seperate-wicket-projects-into-a-multi-module-maven-project-tp4096207p4103152.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: Handling ReplaceHandlerException on continueToOriginalDestination in wicket 1.5

[Martin Grigorov]

On Thu, Nov 24, 2011 at 10:43 AM, Wilhelmsen Tor Iver
 wrote:
>> continueToOriginalDestination() does alway sthrow the replacehandler
>> exception. this is how that method works...
>
> In 1.5 perhaps, in 1.4 it returns false if it was not a redirect; that might 
> be the cause of confusion.

The behavior is the same as in 1.4.x

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



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

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

RE: Handling ReplaceHandlerException on continueToOriginalDestination in wicket 1.5

[Wilhelmsen Tor Iver]

> continueToOriginalDestination() does alway sthrow the replacehandler
> exception. this is how that method works...

In 1.5 perhaps, in 1.4 it returns false if it was not a redirect; that might be 
the cause of confusion.

- Tor Iver

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

Re: Socket write error occurs when you use a modal window wiht Internet Explorer.

[Masaya Seko]

Thank you.
I also sounds similar to it.
I will comment on WICKET-3869.

--- On Thu, 2011/11/24, Martin Grigorov  wrote:

> Hi,
> 
> Sounds similar to https://issues.apache.org/jira/browse/WICKET-3869
> 
> On Thu, Nov 24, 2011 at 4:46 AM, Masaya Seko  wrote:
> > Hi,
> >
> > I using wicket 1.5.3.
> > When using a modal 
> > window(org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow) 
> > with IE, I'm having trouble socket write error.
> > is called when AbstractResource#setResponseHeaders, with high probability 
> > to cause trouble.
> >
> > When rendering modal window, sometimes not called 
> > AbstractResource#setResponseHeaders.
> > if so, socket write error does not occur.
> >
> > The root problem is unknown.
> >
> > I want to know how to prevent a socket write error.
> >
> >
> > The following stack trace:
> > org.apache.wicket.protocol.http.servlet.ResponseIOException: 
> > ClientAbortException:  java.net.SocketException: Connection reset by peer: 
> > socket write error
> >    at 
> > org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:255)
> >    at 
> > org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:92)
> >    at 
> > org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:611)
> >    at 
> > org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:485)
> >    at 
> > org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:77)
> >    at 
> > org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:105)
> >    at 
> > org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
> >    at 
> > org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
> >    at 
> > org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
> >    at 
> > org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
> >    at 
> > org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
> >    at 
> > org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
> >    at 
> > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
> >    at 
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> >    at 
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> >    at 
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> >    at 
> > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> >    at 
> > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> >    at 
> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> >    at 
> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> >    at 
> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
> >    at 
> > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
> >    at 
> > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
> >    at 
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
> >    at java.lang.Thread.run(Thread.java:662)
> > Caused by: ClientAbortException:  java.net.SocketException: Connection 
> > reset by peer: socket write error
> >    at 
> > org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:319)
> >    at 
> > org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288)
> >    at org.apache.catalina.connector.Response.flushBuffer(Response.java:549)
> >    at 
> > org.apache.catalina.connector.ResponseFacade.flushBuffer(ResponseFacade.java:279)
> >    at 
> > org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:251)
> >    ... 24 more
> > Caused by: java.net.SocketException: Connection reset by peer: socket write 
> > error
> >    at java.net.SocketOutputStream.socketWrite0(Native Method)
> >    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> >    at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> >    at 
> > org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:760)
> >    at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:432)
> >    at 
> > org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:318)
> >    at 
> > org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:985)
> >    at org.apache.coyote.Response.action(Response.java:183)
> >    at 
> > org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:314)
> >    ... 28 more
> >
> >
> > 

Re: WiQuery vs JQWicket

[Ernesto Reinaldo Barreiro]

Did you look at [1]? Implementation is not complete (not all the
features of grid are implemented) but it could give you some starting
point.

Regards,

Ernesto

References,

1-http://wiquery-plugins-demo.appspot.com/demo/?wicket:bookmarkablePage=:com.wiquery.plugins.demo.GridPage

On Wed, Nov 23, 2011 at 5:26 PM, Brian Mulholland
 wrote:
> As I am looking at them, I am not noticing either implementing the
> jQuery grid, much less the paging scrollbar.  Am I overlooking it?
>
> Brian Mulholland
>
>
> On Wed, Nov 23, 2011 at 10:56 AM, Pointbreak
>  wrote:
>> I've never used either framework, but your question made me curious
>> again. (Years ago I evaluated the existing wicket-jquery integrations
>> and wasn't happy with how they were designed. Since than I've always
>> just used jquery inside wicket, it's not that hard for simple designs,
>> and for complex designs these frameworks may be just to rigid). That
>> being said I just had a quick glance at the projects again and it seems
>> that WiQuery does the integration via Components (i.e. you create an
>> Accordion Component), while JqWicket does the integration via Bahaviors
>> (i.e. you add an AccordionBehavior to an existing Component, e.g. a
>> ListView). The latter (thus using Behaviors) is how I have always done
>> it, feels more natural to me, and is a lot more flexible.
>>
>> On Wednesday, November 23, 2011 10:16 AM, "Brian Mulholland"
>>  wrote:
>>> We are considering WiQuery and JQWicket.
>>>
>>> 1) Which is better and why?
>>> 2) Is one more established or better supported than the other?
>>> 3) Is one more full featured?
>>>
>>> What differentiates the two?
>>>
>>> Brian Mulholland
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

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

Re: Component not found error after ajax page refresh

[Ernesto Reinaldo Barreiro]

I would block the page with an overlay div while page while links are refreshed.

Regards,

Ernesto


On Thu, Nov 24, 2011 at 5:55 AM, jalbert
 wrote:
> I have developed a data list page using Wicket. The list displays rows of
> data with some action links like View or Edit for each row. The page has an
> AbstractAjaxTimerBehavior attached to it. On timer of this behaviour, the
> action links are changed based on the status of the data row. For example
> the user may lose the ability to Edit a row, so the Edit link would no
> longer be available after the ajax page refresh. Randomly users of the page
> are getting the error below. I suspect it occurs when they try to click on
> one of the action links exactly as the refresh is happening. Is there any
> way I can prevent the user from clicking on a link when the page is being
> refreshed and resolve this error? It occurs randomly and is very hard to
> replicate.
>
> This is the stack trace:
>
> org.apache.wicket.protocol.http.request.InvalidUrlException:
> org.apache.wicket.WicketRuntimeException: component layout:
> inspectionListForm:currentInspections:currentInspectionsListPanel:inspectionEntries:body:rows:1:cells:8:cell:actionLinks
> Container:actionLinks:1:cols:2:actionLinkPanel:editInspectionLink not found
> on page au.gov.wa.dpi.trelis.web.vehicleinsp
> ection.inspectionList.InspectionListPage[id = 16], listener interface =
> [RequestListenerInterface name=ILinkListener, me
> thod=public abstract void
> org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
>        at
> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:262)
>        at org.apache.wicket.RequestCycle.step(RequestCycle.java:1310)
>        at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428)
>        at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
>        at
> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479)
>        at
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312)
>        at
> weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
>        at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.doIt(WebAppServletContext.java:3684)
>        at
> weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3650)
>        at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
>        at
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
>        at
> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2268)
>        at
> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2174)
>        at
> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1446)
>        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
>        at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
> Caused by: *org.apache.wicket.WicketRuntimeException: component
> layout:inspectionListForm:currentInspections:currentInspe
> ctionsListPanel:inspectionEntries:body:rows:1:cells:8:cell:actionLinksContainer:actionLinks:1:cols:2:actionLinkPanel:edi
> tInspectionLink not found on page*
> au.gov.wa.dpi.trelis.web.vehicleinspection.inspectionList.InspectionListPage[id
> = 16],
>  listener interface = [RequestListenerInterface name=ILinkListener,
> method=public abstract void org.apache.wicket.markup
> .html.link.ILinkListener.onLinkClicked()]
>        at
> org.apache.wicket.request.AbstractRequestCycleProcessor.resolveListenerInterfaceTarget(AbstractRequestCyclePr
> ocessor.java:426)
>        at
> org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.jav
> a:471)
>        at
> org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:144)
>        ... 15 more
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Component-not-found-error-after-ajax-page-refresh-tp4102756p4102756.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
>
>

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

Re: Socket write error occurs when you use a modal window wiht Internet Explorer.

[Martin Grigorov]

Hi,

Sounds similar to https://issues.apache.org/jira/browse/WICKET-3869

On Thu, Nov 24, 2011 at 4:46 AM, Masaya Seko  wrote:
> Hi,
>
> I using wicket 1.5.3.
> When using a modal 
> window(org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow) with 
> IE, I'm having trouble socket write error.
> is called when AbstractResource#setResponseHeaders, with high probability to 
> cause trouble.
>
> When rendering modal window, sometimes not called 
> AbstractResource#setResponseHeaders.
> if so, socket write error does not occur.
>
> The root problem is unknown.
>
> I want to know how to prevent a socket write error.
>
>
> The following stack trace:
> org.apache.wicket.protocol.http.servlet.ResponseIOException: 
> ClientAbortException:  java.net.SocketException: Connection reset by peer: 
> socket write error
>    at 
> org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:255)
>    at 
> org.apache.wicket.protocol.http.HeaderBufferingWebResponse.flush(HeaderBufferingWebResponse.java:92)
>    at 
> org.apache.wicket.request.resource.AbstractResource.setResponseHeaders(AbstractResource.java:611)
>    at 
> org.apache.wicket.request.resource.AbstractResource.respond(AbstractResource.java:485)
>    at 
> org.apache.wicket.request.handler.resource.ResourceRequestHandler.respond(ResourceRequestHandler.java:77)
>    at 
> org.apache.wicket.request.handler.resource.ResourceReferenceRequestHandler.respond(ResourceReferenceRequestHandler.java:105)
>    at 
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750)
>    at 
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
>    at 
> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252)
>    at 
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209)
>    at 
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280)
>    at 
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
>    at 
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
>    at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>    at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>    at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>    at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>    at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>    at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>    at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>    at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>    at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
>    at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
>    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
>    at java.lang.Thread.run(Thread.java:662)
> Caused by: ClientAbortException:  java.net.SocketException: Connection reset 
> by peer: socket write error
>    at 
> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:319)
>    at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:288)
>    at org.apache.catalina.connector.Response.flushBuffer(Response.java:549)
>    at 
> org.apache.catalina.connector.ResponseFacade.flushBuffer(ResponseFacade.java:279)
>    at 
> org.apache.wicket.protocol.http.servlet.ServletWebResponse.flush(ServletWebResponse.java:251)
>    ... 24 more
> Caused by: java.net.SocketException: Connection reset by peer: socket write 
> error
>    at java.net.SocketOutputStream.socketWrite0(Native Method)
>    at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
>    at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
>    at 
> org.apache.coyote.http11.InternalOutputBuffer.realWriteBytes(InternalOutputBuffer.java:760)
>    at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:432)
>    at 
> org.apache.coyote.http11.InternalOutputBuffer.flush(InternalOutputBuffer.java:318)
>    at 
> org.apache.coyote.http11.Http11Processor.action(Http11Processor.java:985)
>    at org.apache.coyote.Response.action(Response.java:183)
>    at 
> org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:314)
>    ... 28 more
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

-
To u