voyent
Messages posted by: JoeK  XML
Profile for JoeK -> Messages posted by JoeK [41] Go to Page: 1, 2, 3 Next 
Author Message
We're seeing the same problem. Any resolution?

For now we're rolling back to 1.6.1
I am to the point where I need to write a new component that extends IceFaces' DataTable. Because of the dynamic nature of this table, and the dynamic nature of Groovy, I was considering writing the component in Groovy.

Has anyone tried this? If nothing else, I think it would be interesting to see if it even possible.

Thanks!

JoeK
The scenario we have is something like this:

We have a DataTable with check boxes, output text, input text, and command links. You can click on the command link to bring up a form to edit the table row (don't ask why we didn't just allow for editing on the table..complicated explaination).

So anyway, when you would modify the entry from the form, the changes would be saved to the database and to the DataTable's data as desired, but the changes would not be reflected in the DataTable page. It would still contain the original, unedited data.

After a whole lot of playing with this problem, including following the directions of a lot of posts here, and at the MyFaces Wikii, what finally did the trick in this case was to basically blow the table's backing bean out of the session when the form edit is complete so that IceFaces has to recreate it.

I did this a little something like this:

Code:
    /**
      * Method to get the session from the FacesContext
      *
      * @return HttpSession
      */
     public static HttpSession getSession() {
         FacesContext ctx = FacesContext.getCurrentInstance();
 
         ExternalContext externalContext = null;
 
         if (null != ctx) {
             externalContext = ctx.getExternalContext();
         }
         HttpSession session = null;
         if (null != externalContext) {
             session = (HttpSession) externalContext.getSession(false);
         }
         return session;
     }
 
     public static void killTable(String managedBeanName) {
         HttpSession session = getSession();
         if (null != session) {
             session.removeAttribute(managedBeanName);
             session.removeAttribute("1/com.icesoft.faces.sessionAuxiliaryData");
         }
     }
 


Just pass the managedBeanName as defined in your faces-config.xml file, and it will tear that sucker right out of the session and rebuild the table from the ground up. Works every time. And I didn't notice any real obvious performance hit.

Hope that helps someone.

JoeK
I have found that using columnStyles and ice:columns together does not work. I have also found some posts here that suggest this to be true.

So...any suggestions for having different styles per column while using ice:columns?

The problem here is that the number of columns isn't known until runtime, so I even went so far as generating what columnStyles uses dynamically at runtime, but, yep, that didn't work.

So let's say I want any column that is representing a ColumnSpacer object (could be anything) to have, say, a black background...how would I do that?

Thanks for your help.

Joe

margonz wrote:
I talked to tech support and they helped me with the issue. Basically, setting the connectionTimeout contect-param DOES work, however, the client must clear his/her cache before the new value is set. Anyway, this is how I fixed my problem. If you set a new connectionTimeout and it doesn't seem to be working then clear your browser cache and try again.

 


Great. Thanks!

That browser cache gets me every time. Sometimes it really sucks to be a developer :-)
Anyone know if this has been fixed in 1.6.0?

Thanks!

alikian wrote:
Hi,

With all do respect to your excellent product and effort you made.
Please choose more reasonable deadline for your product, people are relying on you.
Having people trust is most important things in business.

Regards,
Ali 


Wow, Ali,

You really get things done.

One comment, and they release 1.6.0 final. Thanks. I'm impressed :-)

I know this would make my life easier, and suspect it would make your lives easier as well.

I would like to request that you make it easier to subclass your components by 1) having getters and setters for all member variables, 2) referencing the member variables in code with calls to the getters and setters instead of this.varaible, and/or 3) make the member variables protected instead of private.

The specific class I am trying to subclass is the InputFile component. As it stands right now, it looks like I will have to pretty much cut and paste your code instead of subclassing it.

Thanks!
By the way...importing a smaller version of the same file (a 328 k Excel file) works more often than not, though I will occasionally see the same problem.

Oh, and the maximum size allowed in my config files is roughly 1 gb.

Also, I failed to mention this is with 1.6 DR5
The ice:inputFile seems to work super with large files (in this case, "large" being about 3.5 mb)...when I'm running the server and client on the same machine.

If I'm working with a remote computer I get an exception thrown (below). I am able to reproduce this problem by starting a VM on my machine and having that connect to my server (same machine...but with killer bandwidth).

Any ideas?

Thanks!

Code:
11:33:29,146 INFO  [STDOUT] ERROR - Log4JLogger.error(119) | Servlet.service() for servlet uploadServlet threw exception
 java.net.SocketException: Connection reset
         at java.net.SocketInputStream.read(SocketInputStream.java:113)
         at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:747)
         at org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:777)
         at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:115)
         at org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:712)
         at org.apache.coyote.Request.doRead(Request.java:418)
         at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:284)
         at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:404)
         at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:299)
         at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:192)
         at org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:959)
         at org.apache.commons.fileupload.MultipartStream$ItemInputStream.close(MultipartStream.java:910)
         at java.io.FilterInputStream.close(FilterInputStream.java:159)
         at org.apache.commons.fileupload.util.LimitedInputStream.close(LimitedInputStream.java:153)
         at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl$FileItemStreamImpl.close(FileUploadBase.java:714)
         at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.findNextItem(FileUploadBase.java:838)
         at org.apache.commons.fileupload.FileUploadBase$FileItemIteratorImpl.hasNext(FileUploadBase.java:916)
         at com.icesoft.faces.webapp.http.servlet.UploadServlet.service(UploadServlet.java:50)
         at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
         at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
         at com.icesoft.faces.webapp.http.servlet.MainSessionBoundServlet.service(MainSessionBoundServlet.java:93)
         at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.service(SessionDispatcher.java:35)
         at com.icesoft.faces.webapp.http.servlet.PathDispatcher$Matcher.serviceOnMatch(PathDispatcher.java:52)
         at com.icesoft.faces.webapp.http.servlet.PathDispatcher.service(PathDispatcher.java:29)
         at com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:85)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
         at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
         at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:359)
         at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
         at com.icesoft.faces.webapp.xmlhttp.BlockingServlet.service(BlockingServlet.java:54)
         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39)
         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at com.gestalt.affor.cop.web.filter.MessageFilter.doFilter(MessageFilter.java:32)
         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:78)
         at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at org.ajaxanywhere.AAFilter.doFilter(AAFilter.java:46)
         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
         at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
         at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
         at java.lang.Thread.run(Thread.java:613)
Hi Philip,

I think the blind-up/down and drop-in/out effects would work fine.

Is there an example anywhere of how to do AJAX Push to do the effects? I see plenty of examples on how to do this based on a user event (onclickeffect, etc.) but nothing on how to just trigger an event from the server.

I imagine the webmail or auction monitor applications would have to do something like this, so I'll dig in to those, but if you have any easier to dig through examples that would be great.

Thanks for your help.
I'm trying to create a notification panel that will display a message initiated by the server, ever so briefly, and then go away. Much like the "new mail" notification you see in Outlook or Thunderbird.

Another sample can be found by going here http://extjs.com/deploy/ext/docs/index.html clicking on "Dialogs" then "MessageBox and Progress", and then click the "prompt" button, fill in your name, and watch the notification at the top of the screen.

So what I'm thinking about doing is firing off a "Slide Down" event when a "showNotification" method is called server-side, showing the message for about 2 or 3 seconds, and then doing maybe a "Fall Out" event.

Any recommendations on how to accomplish this? (One "easy" way would be to use the EXT JavaScript and just calling that from the server, but that's not very JSF, now is it?)

Thanks!
I'm sorry to hear that ;-)

Maybe it's an issue with the particular build I'm using, or something else odd in our codebase. (I'm using ICEFaces 1.6.0 DR5).

I'll post if I figure out what's going on.

Thanks again!

Joe
Hi Philip,

Thanks for your help.

It looks like the primary difference between what you did (which worked for me) and what I am trying to do (which doesn't work for me) is that you are sending in a static value of "myId" and I'm sending in a binding to a backing bean "#{myBean.id}".

What I find interesting is that while #{myBean.id} is not evaluated properly in the id attribute of the table, it is evaluated right if I put it in another tag (such as ice:outputText), or another attribute.

Could it be that the ID attribute is read before facelets does its magic with ${myBean.id}? In other words, are the id's of components defined before anything else happens?

Thanks again for your help.

JoeK
It just struck me while looking at my code that I posted an alternative version of the table. That was an attempt to work around the problem. The original dataTable tag looks like this:

Code:
<ice:dataTable var="item"
                     id="${tableId}Table"
                     value="${tableBean.rowDataModel}"
                     sortColumn="${tableBean.sortColumnName}"
                     sortAscending="${tableBean.ascending}"
                     rowClasses="oddRow,evenRow"
                     columnClasses="column2"
                     rows="${tableBean.recordsPerPage}" cellpadding="0">


Exact same results in either case, however, the ID is simply "Table"
 
Profile for JoeK -> Messages posted by JoeK [41] Go to Page: 1, 2, 3 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team