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

2011-11-24 Thread 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 m_s...@yahoo.co.jp 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 unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, 

Re: Component not found error after ajax page refresh

2011-11-24 Thread 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
jude.alb...@transport.wa.gov.au 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: WiQuery vs JQWicket

2011-11-24 Thread 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
blmulholl...@gmail.com 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
 pointbreak+wicketst...@ml1.net 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
 blmulholl...@gmail.com 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: Socket write error occurs when you use a modal window wiht Internet Explorer.

2011-11-24 Thread Masaya Seko
Thank you.
I also sounds similar to it.
I will comment on WICKET-3869.

--- On Thu, 2011/11/24, Martin Grigorov mgrigo...@apache.org wrote:

 Hi,
 
 Sounds similar to https://issues.apache.org/jira/browse/WICKET-3869
 
 On Thu, Nov 24, 2011 at 4:46 AM, Masaya Seko m_s...@yahoo.co.jp 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: 

RE: Handling ReplaceHandlerException on continueToOriginalDestination in wicket 1.5

2011-11-24 Thread 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: Handling ReplaceHandlerException on continueToOriginalDestination in wicket 1.5

2011-11-24 Thread Martin Grigorov
On Thu, Nov 24, 2011 at 10:43 AM, Wilhelmsen Tor Iver
toriv...@arrive.no 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: Putting together two seperate wicket projects into a multi-module maven project

2011-11-24 Thread 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: Button with 3 images and issues

2011-11-24 Thread 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: add resources to javascript

2011-11-24 Thread 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: wicket-cdi NotSerializableException for injected SLSB proxy

2011-11-24 Thread 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 ph...@leadseeker.co.uk 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: There are problems with object wicket:id=report width=350 height=100/

2011-11-24 Thread 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

2011-11-24 Thread Igor Vaynberg
On Thu, Nov 24, 2011 at 4:03 AM, Phill ph...@leadseeker.co.uk 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 ph...@leadseeker.co.uk 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

2011-11-24 Thread Igor Vaynberg
btw, feel free to open an issue in wicket-cdi

-igor

On Thu, Nov 24, 2011 at 4:03 AM, Phill ph...@leadseeker.co.uk 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 ph...@leadseeker.co.uk 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: Forms marked as multipart do not work with ajax and IE9

2011-11-24 Thread 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 waynemailingli...@gmail.com 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 ajax-response

 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: AjaxSelfUpdatingTimerBehavior stops working for a while

2011-11-24 Thread 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:
-1wicket:ignoreIfNotActive=truerandom=0.2869209546584387
INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (1627 characters)
INFO:
?xml version=1.0 encoding=UTF-8?ajax-responseheader-contribution
encoding=wicket1 /header-contributioncomponent id=refresh_panel4d1
/componentcomponent id=save4d4
/componentevaluate/evaluate/ajax-response

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:
-1wicket:ignoreIfNotActive=truerandom=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 lt;vicky-ramones@gt; 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: AjaxSelfUpdatingTimerBehavior stops working for a while

2011-11-24 Thread 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 lt;vicky-ramones@gt; 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: wicket-cdi NotSerializableException for injected SLSB proxy

2011-11-24 Thread 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 ph...@leadseeker.co.uk 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 ph...@leadseeker.co.uk 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: There are problems with object wicket:id=report width=350 height=100/

2011-11-24 Thread andreyich
And if it possible could you answer on another question!

What I did wrong?



Java
JRResource pdfResource = new
JRConcreteResourcePdfResourceHandler(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
JRConcreteResourcePdfResourceHandler(reportFile,
new
PdfResourceHandler()).setReportParameters(parameters).setReportDataSource(new
JRBeanCollectionDataSource(historyReports));
add(new ResourceLinkVoid(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



WebResource in Wicket 1.5

2011-11-24 Thread 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