Rajneesh K Rajput

1. compareTo() takes just one argument.
If your class implements Comparable, i.e. you can only compare two of your same objects with one type of comparision logic.


2. Collects provides a mechanish for sorting by using Comparator interface.
This can be used in conjuction to create any no. of comparision logic, with any type of objects either in desc and asc order.

Advantages:
- You don't need to modify class code, which instance needs to be compared.
- You don't need to stick to one sorting logic and bind that with instances itself. (Covers in first step.)

Example:
List<String> myList = new ArrayList<String>(); myList.add("A"); myList.add("B"); myList.add("C"); Collections.sort(myList, new Comparator<String>() { @Override public int compare(String first, String second) { return second.compareTo(first); } }); for(String out : myList) System.out.println(out);

This will give following output...
C
B
A

What threshold of memory consumtion can make a java process resulted in non responsive mode?

This could be tricky, as obviously something wrong either a memory leak or insufficient memory, but still is there a way to decide a memory consumption threshold so that a service or process can be killed manually before a level of non-responsive mode due to memory usage increasing gradually.

Any thoughts?

Is this possible to use same hibernate session over multiple RMI calls?

In my application, these RMI calls obviously involves various method invokes, using load balancer, over different servers, but all of these calls actually being used for originally in a single thread. RMI is configured using Spring.

Is there any configuration, which can help to use single hibernate session throughout all RMI calls, to avoid using separate db connections unnessarily.

java.lang.NoSuchMethodException: java.lang.Class.setValue(com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl) almost clarily explaining the problem is with below lines.

l_resultObject = l_method.invoke(p_object,l_params);

This could be problem with the dynamic method call, because it does not exists in the jar version which is currently in use.

Please verify at run time, all required prerequisits i.e. class name, method name and parameter list are correct and in order as required.

Yes, it is expected that "Value is not a valid option" will be shown because you have changed the value options using Java Script, and when page gets submitted JSF restore the view and this new selected value might not be matching with any of the previous options.

So, what you need to do is you need to change mechanism (where values are dependent, textbox value), which is responsible to update the values at server side not only client side just by using Java Script, so that in restore phase it always aware of with the last entered value in the text field.

1) Please check- t:saveState and try binding text field value with t:saveState and make sure that while generating values for dropdown it picks text filed value from binding variable.

OR
2) Use some in-build Ajax framework, like RichFaces very powerful for JSF to implement such features using ajaxSubmit tag.

Are you are sure, you need to do this? If you are using radio buttons, and they are all part of same id, one of them will always be selected.
There is no way that you can deselect all, once one of them is already selected.

And, by default to keep one as selected once page is rendered you can use value attribute, to display default selected component.

In order to do above, simply check if your checkVal is null then simply fill this with default value, before returning in getter of the same. This will take care of everything.

sathish Tl wrote:
How can we reduce the response time(render time) of page containing the 30-40 richface components

Yes, rendering for 30-40 components could be slow but not that much. We have used lots of components in a single page.

You can try to figure out if it is really components, or the queries involved and taking time itself to provide data to JSF page.

You can see, if there are proper null checks added while filling values for the components specially if values are being populated by hitting database.
This is the major factor, if methods calls again will hit unnecessarliy to database for the same value.

Hi Swaminathan,

Actually, it is simple and expected for each new user (web-request) a different thread is created. So, don't consider just two the no. of threads will vary based on the various parallel request submitted for that specific page view. Also, you should consider that JSF sends separate request for each of images, scripts etc also, and the situation will become worst if your images and scripts are binding on the same page view and using render etc on the same method and which solely is responsible to insert update this list.

1) You simply, have to handle the list update/insert in thread safe mode if you are putting page bean to session scope, or higher.

So, what I see in your code is that this method fetchStatusList() is public. And is there any possibility that it mighe be called directly by some other component (mentioned above) also in your JSF page, please recheck that?

very helpful, and nicely explained.
Thanks.

I am interested to discuss the practical usage of inner classe.