Messages posted by "errorken"

Re:Cancel long running operations

errorken — GMT

I dont understand how this will help me. My situation is like this: I have a typical search/result screen, wich has some input criteria followed by a datatable for displaying the results. The user enters some criteria and then hits 'search' By default the ice:commandButton sends out an ajax request to the blocking servlet for processing. The browser will be blocked untill a reponse is received and then the datatable is populated with the results. Normally this is all there is too it. However, imagine that this search can take 1minute on average. After the user hits 'submit' he realizes that one of the input criteria is wrong, so he wants to abort , modify the criteria and start the search over gain. Now, with the default behaviour this is not possible. Clicking 'stop' on the browser will not work since its an ajax request. The user cannot navigate in the form since ICEFaces blocks the UI, the only thing he can do is wait untill the search finishes. So what I need is to kill the running ajax connection so that the browser is responsive again to input from the user. (I know that the thread on the server side will continue to execute the previous search, but that is ok.)

Re:Cancel long running operations

errorken — GMT

Can I get hold of the javascript objects that regulate the connection? Maybe I can shutdown existing http connections so that full control is regained in the browser or something...

Cancel long running operations

errorken — GMT

I have an action bound to a ice:commandButton. The action being executed takes a long time to process, is there a way to cancel this? Out of the box a click on the commandbutton launches an ajax request which will keep on running... I'm not intereseted in stopping the action on the server side persé. This thread may continue to run, I'm just looking for a way to 'free up' the browser so that a client can continue browsing. Right now when an ajax request is launched the UI freezes (in our case we have the output status showing a progress bar). The only way to do something else on the UI is to navigate to that page again or open/close browser.

Re:Rowselector selects every row in the datatable (even when one row is clicked exactly once)

errorken — GMT

This is still present in ICEFaces 1.8.0. I would like that the value binding for the unique boolean property becomes optional. as illustrated by ICEfaces 1.7.0 there is no technical need to have such a property to mark a row selected. In the JSF world some may decide to use the ListDataModel to capture the row which was selected instead of adding properties to the objects being shown in the datatable. There a couple of scenario's possible where you simply have no control over the objects being shown (you cannot change them, and thereby not being able to add such boolean property). There is also the case of simple objects, where you simply cannot anything to them.

Re:ICEFaces 1.8.0 view/composition bug

errorken — GMT

anyone?

ICEFaces 1.8.0 view/composition bug

errorken — GMT

Our view layout consists of two halves (left & right) which each compose 50% of the screen. You can see it as two forms, on on the left side, the other on the right. Each form consists of a datatable and inside it re-uses a facelets component. There is also a third page, the popup, which will re-use one of the two search forms (either left or right). Thus it will just re-use one of the two datatables via inclusion of the correct xhtml (left or right). For my small example I made it static, so when opening the popup the right side xhtml is always included. Since there is a lot of reuse going on there is some parameterisation where the includes are made. This test project is a strip down from a bigger application, so don't question the parameterisation, it makes sense in the real application :) I stripped everything of, just leaving the bare components needed to illustrate this issue. ---- The issue: First, when you hit the search button the right side will display two lines in the datatable. (see ICEFacesIssues-images.zip#ICEFacesIssue1.jpg) When you click the checkbox on the second line and you click 'open popup' you will get the third table, which is actually the table from the right side re-used. (see ICEFacesIssues-images.zip#ICEFacesIssue2.jpg) Now, when you click the checkbox on that popup you'll get: Code:

Property 'childProperty' not found on type test.ChildX

(see ICEFacesIssue3.jpg) Well, thats correct, childX doesn't have a property 'childPropertyy' (childX has property 'childPropertyx'). But why is it complaining about this? We are cleary re-using the right form, and the right form does not pass 'childpropertyy' as parameter but 'childpropertyx' ! So, one way or the other JSF/ICEfaces is getting confused and is applying the wrong parameter to the table I'm reusing. The attached test project which demonstrates this issue. As far as I can see we are not doing anything wrong here, its just a simple composition of pages and components. It has something to do with the ui:repeat tag. When I replace the collection of childs by a single child, and remove the ui:repeat, the problem is gone. I'm reporting this as a bug, since this works fine with ICEFaces 1.7.1 (didn't try 1.7.2)... Btw; the versions used are mentioned in the ICEFacesIssues-images.zip#ICEFacesIssue-versions.jpg (its SWF 1.0.6, JSF 1.2_12)

Re:Using plain JSF and ICEFaces simultaneously

errorken — GMT

Well, the problem is not related to other component libraries. I was securing an application and I wanted to also to secure the /xmlhttp and /block callbaks. So these URL's are in the 'secured' zone. The login page is in the 'public' zone. When accessing the public page ICEFaces is already making callbacks to /xmlhttp and/or /block. This makes the application go in an infinite loop, since it needs to authenticate for these URL's, making it forward to the login page and then again callbacks to /xmlhttp and/or /block and so on. I changed the login page to not use any ice components, but that didn't change anything. So then I wanted to assign the faces servlet for the login page and the ice servlet for the rest, but that triggered the nullpointer... But maybe you're correct: justice should be the solution if I understand the reference guide correctly

Re:Using plain JSF and ICEFaces simultaneously

errorken — GMT

Anyone an idea about this?

Using plain JSF and ICEFaces simultaneously

errorken — GMT

A couple pages in my application must not be ICEFaces aware. They should be processed like standard JSF pages. So no ajax magic or other asynch callbacks. To accomplish this I'm mapping these pages to the normal faces servlet. However, when I do this I get a NPE :

java.lang.NullPointerException at com.icesoft.faces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:76) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:239)

My setup: Code:

  
    Faces Servlet
    Faces Servlet
    javax.faces.webapp.FacesServlet
    1
  
  
  
    Persistent Faces Servlet
    
			com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet
		
    1
  

  
    Blocking Servlet
    
			com.icesoft.faces.webapp.xmlhttp.BlockingServlet
		
    1
  
  
  
    Blocking Servlet
    /block/*
  
  
  
    Faces Servlet
    *.jsf
  

  
    Persistent Faces Servlet
    *.ice

So whenever I access a page with the 'jsf' extension I get the nullpointer. Am I doing something wrong here ?

Re:Rowselector selects every row in the datatable (even when one row is clicked exactly once)

errorken — GMT

Mark: is there a reason why the rowSelector must bind to a boolean property when multiple=false? When using a listDataModel you can use the listDataModel functionality to retrieve the selected row, so there is no need to have an additional property on the classes itself. Further more, if you are using the ListDataModel with for example plain String's, where are you going to set the boolean property? Its my believe that the value on the rowSelector should be optional and not using it should not trigger the behavior where all rows get selected. I also noticed an entry from Krashan Brahmanjara on this Jira issue :

True. Code from current revision 18231 destroys old behaviour of row selector. On paged list is ok but on scrollable list multiple=false not work. Quick solution. I my environment I restore code component///RowSelector.java from revision 17940 without new enhanced feature. It works good.

So its indeed a bug then? Can this be fixed?

Re:Rowselector selects every row in the datatable (even when one row is clicked exactly once)

errorken — GMT

Ok, when I return a list of objects having a boolean property (and I bind the value of the row selector to that boolean property) it works. But I don't understand why its required to have the value set to a boolean property? We normally use the datatable in combination with a ListDataModel. This offers allready functionality for retrieving the selected row (getRowData/getRowIndex). So now we have to foresee a 'selected' property on all our objects we use in the ListDataModel? (which we will not use, since we use the ListDataModel to determine which row was selected...)

Rowselector selects every row in the datatable (even when one row is clicked exactly once)

errorken — GMT

With ICEFaces 1.7.2 SP1 clicking on a row in a datatable having a rowselector, gets all the rows selected. When reverted to 1.7.1 the problem was gone. I tested this within an isolated test project, with a single page, containing a single action/datatable/rowselector. When I run it with 1.7.2 (SP1) or higher, I get the multiple row select problem. When I run the same projec with 1.7.1 its goes as expected. As you can see in the attached image, I hover my mouse over a row, the row gets light blue (ok) then I click on that row and suddenly every row gets dark blue (= selected = not ok) The code for the table/action is attached. I also checked the docs for possible configuration changes that need to be applied starting from 1.7.1+ but I found none in regards to the rowSelector...

ICEFaces 1.7.2 SP1 not working with webflow 1.0.6

errorken — GMT

After reporting some issues, but never getting any decent response, there is still a problem with webflow 1.0.6 with the 1.7 branch of icefaces. 1.7.2 had state problems where in 1.7.2 SP1 the page doesn't redirect when you start a flow. So nothing is happening basically. Since we are possibly in need of a migration to 1.7.2 SP1 I looked at this problem. As far as I can tell there is a 'renderResponse()' in View on line 150 (method: updateOnPageRequest). What happens is that in that method ICEFaces detects the the GET (as part of the POST/REDIRECT/GET) a refresh. When calling renderResponse() the webflow internals do not get a chance to execute. When executing the renderREsponse phase there is no restored flowExecution (since the previous phases didn't execute) and therefore nothing is prepared. The result is that the page remains the same. Removing this renderResponse() solves the problem and has, as far as I can tell, no side effects on normal refreshes. Can anyone from the ICEFaces team have a look at this problem/solution? http://jira.icefaces.org/browse/ICE-3845 http://jira.icefaces.org/browse/ICE-3713 http://jira.icefaces.org/browse/ICE-3689 http://jira.icefaces.org/browse/ICE-3664

Re:IceFaces 1.7.1 release deadlock on session invalidation

errorken — GMT

We have the same problem with 1.7.1 Since we cannot upgrade to 1.7.2 SP1; it breaks with SWF 1.0.6 and icefaces is not responding to our Jira entries. Because of this we had to make a custom build of 1.7.1 with the locking fixes applied. We took the fixes as posted in the first post. However, this did not fix our problem; still locking issues. After looking at the dumps we saw there is another problem: T1: in SessionDispatcher the method notifySessionShutdown is executed. This is triggered by the de 'scan' thread in SessionDispatcher which scans every 10seconds -> now holding lock on SessionMonitors T2: an expire of the session happens -> expire on StandardSession is invoked -> expire() locks this() - now holding lock on HttpSession ... T1: calling httpSession.invalidate in notifySessionShutdown T2: As a result of the expire, making callbacks to registered HttpSessionListener's. Calling: SessionDispatcher$Listener -> sessionDestroyed -> calls notifySessionShutdown So, in the last two slices: T1 is in need of a lock on the HttpSession, since thats what invalidate requires if you look into StandardSession. T2 is in need of a lock on SessionMonitors, since its entering notifySessionShutdown. Result: deadlock Code:

"Session Monitor" - Thread t@86
   java.lang.Thread.State: BLOCKED on org.apache.catalina.session.StandardSession@1ca9290 owned by: ContainerBackgroundProcessor[StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/vfp-portal-pub]]
        at org.apache.catalina.session.StandardSession.isForegroundLocked(StandardSession.java:1291)
        at org.apache.catalina.session.StandardSession.invalidate(StandardSession.java:1397)
        at org.apache.catalina.session.StandardSessionFacade.invalidate(StandardSessionFacade.java:183)
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.notifySessionShutdown(SessionDispatcher.java:190)
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.access$300(SessionDispatcher.java:23)
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor.shutdown(SessionDispatcher.java:274)
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Monitor.shutdownIfExpired(SessionDispatcher.java:279)
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Listener$1.run(SessionDispatcher.java:222)

Code:

"ContainerBackgroundProcessor[StandardEngine[com.sun.appserv].StandardHost[server].StandardContext[/vfp-portal-pub]]" - Thread t@85
   java.lang.Thread.State: BLOCKED on java.util.HashMap@1f03dc9 owned by: Session Monitor
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.notifySessionShutdown(SessionDispatcher.java:171)
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher.access$300(SessionDispatcher.java:23)
        at com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Listener.sessionDestroyed(SessionDispatcher.java:244)
        at com.icesoft.faces.util.event.servlet.ContextEventRepeater.sessionDestroyed(ContextEventRepeater.java:289)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:777)
        at org.apache.catalina.session.StandardSession.expire(StandardSession.java:735)
        at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:646)
        at org.apache.catalina.session.StandardManager.processExpires(StandardManager.java:899)
        at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5506)
        at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1822)
        at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1811)
        at java.lang.Thread.run(Thread.java:595)

We fixed this by using a ConcurentMap for the SessionMonitors. Because of this there is no explicit locking anymore and that solves the problem. A minor issue with this, is that the map could now be iterated over by multiple threads. This could result in multiple 'sessionDestroy()' being called on the SessionDispatcher instances hold in the map. However, since this method only does this; sessionBoundServers.remove(session.getId()); it doesn't really matter if its called multiple times. Also; ConcurMap "allows" concurent modififcation , so its no issue if T1 and T2 have both iterators and are removing items from the map.

Re:As of SP1 webflow 1.x does not work anymore (when starting flow page does not change)

errorken — GMT

Any progress on this ?