Re: Configure ConversationContext timeout in Orchestra

[Jacob Mathew]

What is the motivation for setting a timeout for the context? Ultimately you
are interested in the deletion of beans in a conversation right? Can you not
achieve that by setting the timeouts on the conversations directly? Every
bean in a conversationContext is inside a conversation...
-Jacob

On Fri, Dec 12, 2008 at 11:40 AM, Steve Ronderos wrote:

>
> Hello Users,
>
> I've looked around for documentation on how to override the 30 minute time
> out default that is set for ConversationContext in Orchestra.
>
> I'm able to configure the Conversation timeout fine for both
> conversation.access and conversation.manual, but I have been unable to find
> the configuration for ConversationContexts.
>
> Does anyone know how I can configure this setting?
>
> Thanks,
>
> Steve Ronderos

Re: AW: [Trinidad] Generate PDF _and_ close dialog

[Stephen Friedrich]

Thanks for the answers!
I got it working by setting the parameters for pdf generation to a hidden input
field that is refreshed using PPR when the dialog closes.
A ppr state listener then checks for the content of that field and simply sets
window.location to the url for the pdf servlet.
This avoids a second browser window that will just be empty anyway.

Döring Markus wrote:

You can not do this in one request because you can have either HTML (or XHTTP) 
content OR PDF content in one response.
One solution to workaround this is to fire the action, close the dialog and add 
an JS that submits a (hidden) button to download the PDF _after_ the dialog has 
been closed.

-Ursprüngliche Nachricht-
Von: Stephen Friedrich [mailto:trini...@eekboom.com] 
Gesendet: Dienstag, 9. Dezember 2008 00:17

An: MyFaces Discussion
Betreff: [Trinidad] Generate PDF _and_ close dialog

I'd like to (well - have to) make a Trinidad (lightweight) dialog close when a
command button is clicked and at the same time create a PDF and send it in the 
response.

Any idea?
Currently I can either configure the http response to be the pdf or I can close
the dialog using returnFromDialog().

Configure ConversationContext timeout in Orchestra

[Steve Ronderos]

Hello Users,

I've looked around for documentation on how to override the 30 minute time 
out default that is set for ConversationContext in Orchestra. 

I'm able to configure the Conversation timeout fine for both 
conversation.access and conversation.manual, but I have been unable to 
find the configuration for ConversationContexts.

Does anyone know how I can configure this setting?

Thanks,

Steve Ronderos

ist außer Haus

[Juergen . Wieners]

Ich werde ab  12.12.2008 nicht im Büro sein. Ich kehre zurück am
07.01.2009.

Ich wünsche allen ein frohes Fest und einen guten Rutsch ins neue Jahr.

Bis bald im neuen Jahr

Euer Jürgen

ist außer Haus

[Juergen . Wieners]

Ich werde ab  12.12.2008 nicht im Büro sein. Ich kehre zurück am
07.01.2009.

Ich wünsche allen ein frohes Fest und einen guten Rutsch ins neue Jahr.

[Trinidad] supported browsers?

[Bruno Marti]

Is this page currently up-to-date?
http://myfaces.apache.org/trinidad/browsers.html

-- 
View this message in context: 
http://www.nabble.com/-Trinidad--supported-browsers--tp20977454p20977454.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

How to re-/set a value in a trinidad table after dialog popup

[wolfgang . toepfer]

Hi, 

We have a problem here when resetting the value of an input component like 
tr:inputText that is in a Trinidad table.
The following context is given:

1) the user clicks on a commandLink object that is in the same cell next 
to the inputComponent
2) a popup dialog is displayed, the user select a value or cancels it
3) if cancelled, the old value is reset, if not and a value has been 
selected, the new value is set 

The problem is that, because of the stamping,  it seems difficult to reach 
the input component where the value is re-/set.
I thought we could use varStatus as an option but we have difficulty using 
it.

Thus my question: has anyone a running little example or may be able to 
jot down the approach with varStatus?

Thanks a lot in advance!

Best wishes and a merry Xmas time,
Wolfgang.

Re: [Tobago] Unable to populate Sheet

[Giovanni De Stefano]

Again wrong attachment... :-(

-
<%@ taglib uri="http://myfaces.apache.org/tobago/component"; prefix="tc"%>
<%@ taglib uri="http://myfaces.apache.org/tobago/extension"; prefix="tx"%>
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>


























-


On Fri, Dec 12, 2008 at 2:25 PM, Giovanni De Stefano <
giovanni.destef...@gmail.com> wrote:

> Hello Helmut,
>
> thank you for your reply. Yes, the was the bad side effect of copy and
> paste... :-(
>
> Attached is a sand box test about the sheet: I still cannot populate the
> sheet.
>
> What am I missing?
>
> Thanks,
> Giovanni
>
>
> On Fri, Dec 12, 2008 at 1:33 PM, Helmut Swaczinna 
> wrote:
>
>>  Hi,
>>
>> you're using a wrong variable name in the tc:out on the sheet column. It
>> should be item, not channel.
>>
>> Regards
>> Helmut
>>
>> - Original Message -
>>  *From:* Giovanni De Stefano 
>> *To:* users@myfaces.apache.org
>> *Sent:* Friday, December 12, 2008 12:57 PM
>> *Subject:* Re: [Tobago] Unable to populate Sheet
>>
>> Apparently I was not supposed to attach the jsp...it was filtered out by
>> the mail server.
>>
>> Here it is:
>>
>>
>> --
>> <%@ taglib uri="http://myfaces.apache.org/tobago/component"; prefix="tc"%>
>> <%@ taglib uri="http://myfaces.apache.org/tobago/extension"; prefix="tx"%>
>> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > action="newChannel">
>> > action="editChannel">
>> > action="deleteChannel">
>> 
>> > value="Are you sure you want to delete the
>> selected channel(s)?" />
>> 
>> 
>> 
>> 
>> > state="#{listBean.selectedItems}" showRowRange="left"
>> showPageRange="right" showDirectLinks="center">
>> > rendered="true">
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> --
>>
>>
>> On Fri, Dec 12, 2008 at 12:15 PM, Giovanni De Stefano <
>> giovanni.destef...@gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I have to admit I am a total noobie with MyFaces but I believe Tobago is
>>> a very powerful framework.
>>>
>>> Having said this, I cannot populate a Sheet :-(
>>>
>>> Attached are the beans, the web.xml (tobago-config.xml is pretty
>>> standard), and the JSP page that creates the Sheet.
>>>
>>> In faces-config I declare the beans:
>>>
>>> ...
>>> 
>>> Item bean
>>> itemBean
>>> test.ItemBean
>>> request
>>> 
>>>
>>> 
>>> List bean
>>> listBean
>>> test.ListBean
>>> session
>>> 
>>> ...
>>>
>>> I have the following jars in WEB-INF/lib folder:
>>>
>>> avalon-framework-4.1.3.jar
>>> tobago-core-1.1.0-SNAPSHOT.jar
>>> commons-beanutils-1.7.0.jar
>>> jstl-1.1.0.jar
>>> tobago-jsf-compat-1.1.0-SNAPSHOT.jar
>>> commons-collections-3.1.jar
>>> log4j-1.2.11.jar
>>> tobago-taglib-extension-1.1.0-SNAPSHOT.jar
>>> commons-digester-1.8.jar
>>> logkit-1.0.1.jar
>>> tobago-theme-charlotteville-1.1.0-SNAPSHOT.jar
>>> commons-el-1.0.jar
>>> myfaces-api-1.1.6.jar
>>>  tobago-theme-richmond-1.1.0-SNAPSHOT.jar
>>> commons-fileupload-1.2.jar
>>> myfaces-impl-1.1.6.jar
>>> tobago-theme-scarborough-1.1.0-SNAPSHOT.jar
>>> commons-io-1.1.jar
>>> mysql-connector-java-5.1.7-bin.jar
>>> tobago-theme-speyside-1.1.0-SNAPSHOT.jar
>>> commons-lang-2.1.jar
>>>  tobago-theme-standard-1.1.0-SNAPSHOT.jar
>>> commons-logging-1.1.jar
>>> standard-1.1.2.jar
>>>
>>> The result is that I see the box title and the empty sheet skeleton. No
>>> helpful logs.
>>>
>>> What am I missing?
>>>
>>> Thank you all in advance!
>>>
>>> Giovanni
>>>
>>
>>
>
package test;

/**
 * @author Giovanni De Stefano
 */

Re: [Tobago] Unable to populate Sheet

[Giovanni De Stefano]

Hello Helmut,

thank you for your reply. Yes, the was the bad side effect of copy and
paste... :-(

Attached is a sand box test about the sheet: I still cannot populate the
sheet.

What am I missing?

Thanks,
Giovanni

On Fri, Dec 12, 2008 at 1:33 PM, Helmut Swaczinna wrote:

>  Hi,
>
> you're using a wrong variable name in the tc:out on the sheet column. It
> should be item, not channel.
>
> Regards
> Helmut
>
> - Original Message -
> *From:* Giovanni De Stefano 
> *To:* users@myfaces.apache.org
> *Sent:* Friday, December 12, 2008 12:57 PM
> *Subject:* Re: [Tobago] Unable to populate Sheet
>
> Apparently I was not supposed to attach the jsp...it was filtered out by
> the mail server.
>
> Here it is:
>
>
> --
> <%@ taglib uri="http://myfaces.apache.org/tobago/component"; prefix="tc"%>
> <%@ taglib uri="http://myfaces.apache.org/tobago/extension"; prefix="tx"%>
> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>
>
> 
> 
> 
> 
> 
> 
> 
> 
>  action="newChannel">
>  action="editChannel">
>  action="deleteChannel">
> 
>  value="Are you sure you want to delete the
> selected channel(s)?" />
> 
> 
> 
> 
>  state="#{listBean.selectedItems}" showRowRange="left"
> showPageRange="right" showDirectLinks="center">
>  rendered="true">
> 
> 
> 
> 
> 
> 
>
> --
>
>
> On Fri, Dec 12, 2008 at 12:15 PM, Giovanni De Stefano <
> giovanni.destef...@gmail.com> wrote:
>
>> Hello all,
>>
>> I have to admit I am a total noobie with MyFaces but I believe Tobago is a
>> very powerful framework.
>>
>> Having said this, I cannot populate a Sheet :-(
>>
>> Attached are the beans, the web.xml (tobago-config.xml is pretty
>> standard), and the JSP page that creates the Sheet.
>>
>> In faces-config I declare the beans:
>>
>> ...
>> 
>> Item bean
>> itemBean
>> test.ItemBean
>> request
>> 
>>
>> 
>> List bean
>> listBean
>> test.ListBean
>> session
>> 
>> ...
>>
>> I have the following jars in WEB-INF/lib folder:
>>
>> avalon-framework-4.1.3.jar
>> tobago-core-1.1.0-SNAPSHOT.jar
>> commons-beanutils-1.7.0.jar
>> jstl-1.1.0.jar
>> tobago-jsf-compat-1.1.0-SNAPSHOT.jar
>> commons-collections-3.1.jar
>> log4j-1.2.11.jar
>> tobago-taglib-extension-1.1.0-SNAPSHOT.jar
>> commons-digester-1.8.jar
>> logkit-1.0.1.jar
>> tobago-theme-charlotteville-1.1.0-SNAPSHOT.jar
>> commons-el-1.0.jar
>> myfaces-api-1.1.6.jar
>>  tobago-theme-richmond-1.1.0-SNAPSHOT.jar
>> commons-fileupload-1.2.jar
>> myfaces-impl-1.1.6.jar
>> tobago-theme-scarborough-1.1.0-SNAPSHOT.jar
>> commons-io-1.1.jar
>> mysql-connector-java-5.1.7-bin.jar
>> tobago-theme-speyside-1.1.0-SNAPSHOT.jar
>> commons-lang-2.1.jar
>>  tobago-theme-standard-1.1.0-SNAPSHOT.jar
>> commons-logging-1.1.jar
>> standard-1.1.2.jar
>>
>> The result is that I see the box title and the empty sheet skeleton. No
>> helpful logs.
>>
>> What am I missing?
>>
>> Thank you all in advance!
>>
>> Giovanni
>>
>
>


test.tar.gz
Description: GNU Zip compressed data

Re: [Tobago] Unable to populate Sheet

[Helmut Swaczinna]

Hi,

you're using a wrong variable name in the tc:out on the sheet column. It should 
be item, not channel.

Regards
Helmut
  - Original Message - 
  From: Giovanni De Stefano 
  To: users@myfaces.apache.org 
  Sent: Friday, December 12, 2008 12:57 PM
  Subject: Re: [Tobago] Unable to populate Sheet


  Apparently I was not supposed to attach the jsp...it was filtered out by the 
mail server.

  Here it is:

  
--
  <%@ taglib uri="http://myfaces.apache.org/tobago/component"; prefix="tc"%>
  <%@ taglib uri="http://myfaces.apache.org/tobago/extension"; prefix="tx"%>
  <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>

  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
--



  On Fri, Dec 12, 2008 at 12:15 PM, Giovanni De Stefano 
 wrote:

Hello all,

I have to admit I am a total noobie with MyFaces but I believe Tobago is a 
very powerful framework.

Having said this, I cannot populate a Sheet :-( 

Attached are the beans, the web.xml (tobago-config.xml is pretty standard), 
and the JSP page that creates the Sheet.

In faces-config I declare the beans:

...

Item bean
itemBean
test.ItemBean
request



List bean
listBean
test.ListBean
session

...

I have the following jars in WEB-INF/lib folder:

avalon-framework-4.1.3.jar   
tobago-core-1.1.0-SNAPSHOT.jar
commons-beanutils-1.7.0.jar  
jstl-1.1.0.jar  
tobago-jsf-compat-1.1.0-SNAPSHOT.jar
commons-collections-3.1.jar  
log4j-1.2.11.jar
tobago-taglib-extension-1.1.0-SNAPSHOT.jar
commons-digester-1.8.jar 
logkit-1.0.1.jar
tobago-theme-charlotteville-1.1.0-SNAPSHOT.jar
commons-el-1.0.jar   
myfaces-api-1.1.6.jar  
 tobago-theme-richmond-1.1.0-SNAPSHOT.jar
commons-fileupload-1.2.jar   
myfaces-impl-1.1.6.jar  
tobago-theme-scarborough-1.1.0-SNAPSHOT.jar
commons-io-1.1.jar   
mysql-connector-java-5.1.7-bin.jar  
tobago-theme-speyside-1.1.0-SNAPSHOT.jar
commons-lang-2.1.jar 
 tobago-theme-standard-1.1.0-SNAPSHOT.jar
commons-logging-1.1.jar  
standard-1.1.2.jar

The result is that I see the box title and the empty sheet skeleton. No 
helpful logs.

What am I missing?

Thank you all in advance!

Giovanni

Re: [Tobago] Unable to populate Sheet

[Giovanni De Stefano]

Apparently I was not supposed to attach the jsp...it was filtered out by the
mail server.

Here it is:

--
<%@ taglib uri="http://myfaces.apache.org/tobago/component"; prefix="tc"%>
<%@ taglib uri="http://myfaces.apache.org/tobago/extension"; prefix="tx"%>
<%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%>


























--


On Fri, Dec 12, 2008 at 12:15 PM, Giovanni De Stefano <
giovanni.destef...@gmail.com> wrote:

> Hello all,
>
> I have to admit I am a total noobie with MyFaces but I believe Tobago is a
> very powerful framework.
>
> Having said this, I cannot populate a Sheet :-(
>
> Attached are the beans, the web.xml (tobago-config.xml is pretty standard),
> and the JSP page that creates the Sheet.
>
> In faces-config I declare the beans:
>
> ...
> 
> Item bean
> itemBean
> test.ItemBean
> request
> 
>
> 
> List bean
> listBean
> test.ListBean
> session
> 
> ...
>
> I have the following jars in WEB-INF/lib folder:
>
> avalon-framework-4.1.3.jar
> tobago-core-1.1.0-SNAPSHOT.jar
> commons-beanutils-1.7.0.jar
> jstl-1.1.0.jar
> tobago-jsf-compat-1.1.0-SNAPSHOT.jar
> commons-collections-3.1.jar
> log4j-1.2.11.jar
> tobago-taglib-extension-1.1.0-SNAPSHOT.jar
> commons-digester-1.8.jar
> logkit-1.0.1.jar
> tobago-theme-charlotteville-1.1.0-SNAPSHOT.jar
> commons-el-1.0.jar
> myfaces-api-1.1.6.jar
>  tobago-theme-richmond-1.1.0-SNAPSHOT.jar
> commons-fileupload-1.2.jar
> myfaces-impl-1.1.6.jar
> tobago-theme-scarborough-1.1.0-SNAPSHOT.jar
> commons-io-1.1.jar
> mysql-connector-java-5.1.7-bin.jar
> tobago-theme-speyside-1.1.0-SNAPSHOT.jar
> commons-lang-2.1.jar
>  tobago-theme-standard-1.1.0-SNAPSHOT.jar
> commons-logging-1.1.jar
> standard-1.1.2.jar
>
> The result is that I see the box title and the empty sheet skeleton. No
> helpful logs.
>
> What am I missing?
>
> Thank you all in advance!
>
> Giovanni
>

[Tobago] Unable to populate Sheet

[Giovanni De Stefano]

Hello all,

I have to admit I am a total noobie with MyFaces but I believe Tobago is a
very powerful framework.

Having said this, I cannot populate a Sheet :-(

Attached are the beans, the web.xml (tobago-config.xml is pretty standard),
and the JSP page that creates the Sheet.

In faces-config I declare the beans:

...

Item bean
itemBean
test.ItemBean
request



List bean
listBean
test.ListBean
session

...

I have the following jars in WEB-INF/lib folder:

avalon-framework-4.1.3.jar
tobago-core-1.1.0-SNAPSHOT.jar
commons-beanutils-1.7.0.jar
jstl-1.1.0.jar
tobago-jsf-compat-1.1.0-SNAPSHOT.jar
commons-collections-3.1.jar
log4j-1.2.11.jar
tobago-taglib-extension-1.1.0-SNAPSHOT.jar
commons-digester-1.8.jar
logkit-1.0.1.jar
tobago-theme-charlotteville-1.1.0-SNAPSHOT.jar
commons-el-1.0.jar
myfaces-api-1.1.6.jar
 tobago-theme-richmond-1.1.0-SNAPSHOT.jar
commons-fileupload-1.2.jar
myfaces-impl-1.1.6.jar
tobago-theme-scarborough-1.1.0-SNAPSHOT.jar
commons-io-1.1.jar
mysql-connector-java-5.1.7-bin.jar
tobago-theme-speyside-1.1.0-SNAPSHOT.jar
commons-lang-2.1.jar
 tobago-theme-standard-1.1.0-SNAPSHOT.jar
commons-logging-1.1.jar
standard-1.1.2.jar

The result is that I see the box title and the empty sheet skeleton. No
helpful logs.

What am I missing?

Thank you all in advance!

Giovanni
package test;

/**
 * @author Giovanni De Stefano
 */
public class ItemBean {

	private String name;

	/**
	 *
	 */
	public ItemBean() {

	}

	/**
	 *
	 */
	public ItemBean(String name) {
		this.name = name;
	}

	/**
	 *
	 */
	public String getName() {
		return name;
	}

	/**
	 *
	 */
	public void setName(String name) {
		this.name = name;
	}
}package test;

import java.util.ArrayList;
import java.util.List;

import org.apache.myfaces.tobago.model.SheetState;

/**
 * @author Giovanni De Stefano
 */
public class ListBean {

	private List list;
	private SheetState selectedItems;

	/**
	 *
	 */
	public ListBean() {
		list = new ArrayList();
		for (int i = 0; i < 15; i++) {
			list.add(new ItemBean(i + " ITEM"));
		}
	}

	/**
	 *
	 */
	public void setSelectedItems(SheetState selectedItems) {
		this.selectedItems = selectedItems;
	}

	/**
	 *
	 */
	public SheetState getSelectedItems() {
		return selectedItems;
	}

	/**
	 *
	 */
	public List getItems() {
		return list;
	}

	/**
	 *
	 */
	public void setItems(List list) {
		this.list = list;
	}
}

http://java.sun.com/xml/ns/j2ee"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
	xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
	version="2.4">

	Radio

	
		multipartFormdataFilter
		
			org.apache.myfaces.tobago.webapp.TobagoMultipartFormdataFilter
	
	
		multipartFormdataFilter
		/faces/*
	

	
		FacesServlet
		javax.faces.webapp.FacesServlet
		1
	

	
		ResourceServlet
		org.apache.myfaces.tobago.servlet.ResourceServlet
	

	
		FacesServlet
		/faces/*
	

	
		ResourceServlet
		/org/apache/myfaces/tobago/renderkit/*
	

	
		index.jsp
	



list.jsp
Description: Binary data

RE: Displaying messages over the content - generated by the content?

[Madhav Bhargava]

Madhav Bhargava schrieb:
> felix.bec...@t-systems.com schrieb:
>   
>> Hi,
>>
>> I've got a JSF page divided in 2 parts - the status message area and
>> the content area. The content area is positioned under the status
>> message area. In the status area all messages for the user should be
>> shown - for example success messages, error messages and exceptions.
>> In my content area I've got a > value="#{myBean.values}"..>. When the method getValues() of myBean
>> throws an exception, I'm catching this exception. I want to display
>> this exception in the status message area - but this does not work -
>> apparently because the status area is already rendered when the
>> content el-methods are called. Is there any solution for this problem?
>> Is it possible to render the status area at last?
>>
>> 
> One quick solution can be to call a javascript function on onload. This 
> function can do an ajax submit and re-render the status area of your JSP. If 
> there are any error messages then that will displayed else nothing will be 
> displayed. 
> If you want more control then do not add the FacesMessage to the 
> FacesContext, instead handle it yourself.
>   

Simon wrote:

>Will re-rendering messages using a separate ajax request work?

>FacesMessage objects are attached to the FacesContext, not the view. And
>a FacesContext is a request-scoped object. So AFAIK, a second request
>will always see an empty messages list...

>Regards,
>Simon

Yes you are right. What I was talking about was a simple hack. For specific 
messages like the ones that are generated during the render response you do not 
add it to the FacesContext. Instead you maintain them into a separate list 
whose scope is say conversation scope rather than a request scope. When the 
page is rendered, onbody is called which will see if there are any messages. 
Component like t:messages will inherently read from FacesContext. You can 
create your own component extending say t:messages and read from a different 
source as well.

 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not 
to copy, disclose, or distribute this e-mail or its contents to any other 
person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken 
every reasonable precaution to minimize this risk, but is not liable for any 
damage 
you may sustain as a result of any virus in this e-mail. You should carry out 
your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this 
e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: Thread safety for Orchestra access scope

[Jacob Mathew]

Thank you for the response. I had read the multi-window topic in the
documentation earlier (and also remember thinking it was outstandingly good,
I thank the author).
As far as how bad it can get if a user can (maliciously) concurrently access
non thread safe code even within their own session, I can think of many
contrived examples where the damage can be arbitrarily bad. The first that
came to mind is the following list of commands.

login(root)
runRestrictedCommandsForSetup()
logout()
login(currentUser)
run(inputedUserCommands)
logout()

It's easy to see that when run concurrently, there is a possibility that
inputedUserCommands might run as root, which can be arbitrarily bad. But
there are less contrived examples too. A transaction object might end up
getting shared for multiple threads, and then whole bag of race condition
problems (simultaneous withdrawal from banks, etc.) are in the picture.

I understand what you say about sharing conversationContexts across windows.
I would rather the situation never happens. But unfortunately, as
acknowledged in the documentation, it requires the co-operation of the user,
which is not something I am willing to bank on. In fact, it would seem like
the most natural ways for creating new tabs (right click and select open in
new tab, copying the link) causes the context to be shared. So I do have to
make sure that my application will at least be sound when this happens, if
not predictable to the user.

To me, this means I need to handle

1. Concurrent access to conversation scoped beans
2. Dirty views - i.e. when handling a request I cannot assume that the bean
was in the same state as when the page that sourced this request was
rendered - this subsumes your example of the deleted conversation.

It looks like I don't have to worry about 1 though because of the locking on
the context (except for the border case, but thats too hard to deal with,
I'm going to drop it, unless Orchestra is updated). And for 2 - well, I'm
still investigating how I am going to deal with that on a general basis...

-Jacob

On Thu, Dec 11, 2008 at 11:35 PM, Simon Kitching wrote:

> Hi Jacob,
>
> Thanks very much for your comments.
>
> I don't believe that "guessing the conversationcontextid" is
> significant, because the id is per-session. As you point out, someone
> *can* maliciously try to guess the value, thereby creating race
> conditions for data *in their own session*. But I don't see any way to
> expand that to corrupt data in other sessions or create a
> denial-of-service for anyone else. If you can think of a way someone can
> use this to affect anyone other than themself, please let me know!
>
> Note that having two tabs or windows with the same conversationContextId
> is a bad idea; separate windows should have separate
> conversationContextId values. The per-context locking is really just to
> ensure that things like users double-clicking on a submit button don't
> cause races. If the user can select the same view in two different
> windows, and you use the same conversationContextId (or a session-scoped
> backing bean) then the two windows will interact in unpleasant ways.
> Having different conversationContextIds ensures that the backing bean
> instance is *different* for the two windows, so no nasty interactions
> occur.
>
> Note also that if you want multiple windows, you really should select
> client-side-state-saving.
>
> See here for more details:
>
> http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html
>
> That's the reason there isn't much documentation on the "conversation
> locking" feature of Orchestra; apps should use different
> conversationContextIds for different windows. The locking is just a
> safety measure for some odd corner cases, not a major user feature.
>
> Regards,
> Simon
>
> Jacob Mathew schrieb:
> > It should be noted that the border case where the first request
> > creates a new conversationcontext is not completely sound. In this
> > scenario, no lock is acquired "because nothing else can refer to that
> > newly created [conversationcontext] id until the response for this
> > request has been sent back to the client browser". This is not true.
> > The second request can simply guess the conversationcontext id which
> > is a simple alphanumeric increment. Admittedly not a situation likely
> > to happen unless someone was explicitly trying to break the
> > application, but a legitimate hole nonetheless.
> >
> > -Jacob
> >
> > On Thu, Dec 11, 2008 at 4:14 PM, Jacob Mathew  > > wrote:
> >
> > The source code for Orchestra provided the answer I was looking
> > for. It looks like a lock is acquired on the conversationcontext
> > object corresponding to the request before accessing any of the
> > beans inside of a conversation. So the execution of two requests
> > in the same conversationcontext will not happen concurrently,
> > which mean beans in a conversation (access) scope do

Re: Displaying messages over the content - generated by the content?

[Simon Kitching]

Madhav Bhargava schrieb:
> felix.bec...@t-systems.com schrieb:
>   
>> Hi,
>>
>> I've got a JSF page divided in 2 parts - the status message area and
>> the content area. The content area is positioned under the status
>> message area. In the status area all messages for the user should be
>> shown - for example success messages, error messages and exceptions.
>> In my content area I've got a > value="#{myBean.values}"..>. When the method getValues() of myBean
>> throws an exception, I'm catching this exception. I want to display
>> this exception in the status message area - but this does not work -
>> apparently because the status area is already rendered when the
>> content el-methods are called. Is there any solution for this problem?
>> Is it possible to render the status area at last?
>>
>> 
> One quick solution can be to call a javascript function on onload. This 
> function can do an ajax submit and re-render the status area of your JSP. If 
> there are any error messages then that will displayed else nothing will be 
> displayed. 
> If you want more control then do not add the FacesMessage to the 
> FacesContext, instead handle it yourself.
>   
Will re-rendering messages using a separate ajax request work?

FacesMessage objects are attached to the FacesContext, not the view. And
a FacesContext is a request-scoped object. So AFAIK, a second request
will always see an empty messages list...

Regards,
Simon

-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)

RE: Displaying messages over the content - generated by the content?

[Madhav Bhargava]

felix.bec...@t-systems.com schrieb:
>
> Hi,
>
> I've got a JSF page divided in 2 parts - the status message area and
> the content area. The content area is positioned under the status
> message area. In the status area all messages for the user should be
> shown - for example success messages, error messages and exceptions.
> In my content area I've got a  value="#{myBean.values}"..>. When the method getValues() of myBean
> throws an exception, I'm catching this exception. I want to display
> this exception in the status message area - but this does not work -
> apparently because the status area is already rendered when the
> content el-methods are called. Is there any solution for this problem?
> Is it possible to render the status area at last?
>

>I can't think of an easy solution for this.

>Output generated during rendering is (at least theoretically) sent over
>the network to the remote browser as it is created. So as you point out,
>your "status area" has already been written before you encounter the
>exception. There is no TCP feature to "unsend data".

>
>One obvious option would be to move your status area to the bottom of
>the page.

>Or you could write out the status area at the bottom of the page, then
>use CSS positioning rules to make it *appear* at the top of the page. Or
>use javascript to move the generated messages block from the bottom of
>the page to the top.

>Note that JSF messages created during:
>* conversion
>* validation
>* action-handling
>are no problem. It is only exceptions during rendering that would be an
>issue. I can't think why you would be getting errors during fetching of
>rendered data; I've not had to deal with that before except when wanting
>to display some kind of "result set too large" message. Maybe you can
>move the fetching of this data up into the action method of your bean?>

>Regards,
>Simon

One quick solution can be to call a javascript function on onload. This 
function can do an ajax submit and re-render the status area of your JSP. If 
there are any error messages then that will displayed else nothing will be 
displayed. 
If you want more control then do not add the FacesMessage to the FacesContext, 
instead handle it yourself.

Regards,
Madhav


-- 
-- Emails in "mixed" posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)


 CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are 
not 
to copy, disclose, or distribute this e-mail or its contents to any other 
person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has 
taken 
every reasonable precaution to minimize this risk, but is not liable for any 
damage 
you may sustain as a result of any virus in this e-mail. You should carry out 
your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this 
e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***

Re: Light Weight Dialog is not rendering Select Boxes on initial rendering on IE 6 but works on IE 7

[Bruno Marti]

There is a JIRA-Issue on that, see:
https://issues.apache.org/jira/browse/TRINIDAD-1340
There is also a workaround commented.


Bruno Marti wrote:
> 
> I've detected the same dialog problem in IE6 with a tr:table with multiple
> pages (pagging). 
> The page chooser (drop-down box) isn't displayed on first load of dialog,
> but the links "prev/next" besides the drop-down box are displayed.
> The script below doesn't solve the problem neither.
> 
> (myfaces 1.1.5, trinidad 1.0.10) 
> 
> 
> 
> Richard Yee-3 wrote:
>> 
>> We created the org.apache.myfaces.trinidadinternal.renderkit.core.xhtml
>> package directory under our project source directory and put the
>> ChooseDateRenderer.java class there. The class loader should then pick
>> up the class from the WEB-INF/classes directory before it gets to
>> search the jar. Try putting a logging statement in the code to see if
>> the patched ChooseDateRenderer class is being used.
>> 
>> Note that this patch only fixes the problem with tr:inputDate. There
>> is a general problem with selectOneChoice dropdown lists and
>> lightweight dialogs with IE6. To fix the problem on lightweight
>> dialogs that have dropdown we use the following javascript function
>> 
>> function dialogComponentRefresh() {
>>var arg = dialogComponentRefresh.arguments;
>>for(i=0;i>   if(document.getElementById(arg[i]) != null) {
>> document.getElementById(arg[i]).style.cssText = 'display:
>> inline !important; visibility: visible !important;';
>>   }
>>}
>> 
>> and run it using the onload attribute of the tr:document tag.
>> 
>> We still have the minor problem of select boxes on a page disappearing
>> when a lightweight dialog is displayed and reappearing when the dialog
>> is closed.
>> 
>> 
>> -Richard
>> 
>> On Thu, Dec 4, 2008 at 11:59 AM, Manickam  wrote:
>>>
>>> Sorry we were using ChooseDateRenderer.java , I mistyped it.
>>>
>>> Our problem is that we have quite a few dialog screens where there are
>>> select boxes and shuttle components. Both of these are not rendering
>>> with
>>> light weight dialog and IE 6. Works fine on iE 7 and obviously works
>>> fine on
>>> 6 & 7 with popup dialog.
>>>
>>> Can you let us know how you included this java file into your JDeveloper
>>> Project?
>>>
>>> thanks,
>>> Kannappan
>>>
>>>
>>> Richard Yee-3 wrote:

 Did you get ChooseRenderer.java or ChooseDateRenderer.java? We are
 using ChooseDateRenderer and that fixed the problem with the month and
 year select boxes. We are also using JDeveloper.

 -Richard

 On Thu, Dec 4, 2008 at 11:09 AM, Manickam  wrote:
>
> We added the ChooseRenderer.java downloaded from the JIRA site
> (https://issues.apache.org/jira/browse/TRINIDAD-1071) into our project
> code
> with package as
> "org.apache.myfaces.trinidadinternal.renderkit.core.xhtml"
> and left the trinidad jar file un touched in the WEB_INF/LIB folder.
> This
> didn't take any effect when we ran from JDEVELOPER.
>
> We then tried the second approach where we compiled this class,
> exploded
> the
> trinidad 1.0.10 jar file, took the compiled class(there were 2 because
> of
> subclass) files add included into the exploded trinidad 1.0.10 jar
> replacing
> the original one. Then we rebuilt the jar file and included into our
> project, this didn't solve the issue as well.
>
> thanks,
> Kan
>
>
> Richard Yee-3 wrote:
>>
>> Where did you download the ChooseRenderer.java class from? For the
>> ChooseDateRenderer.java patch, we added the .java file to our sources
>> and it fixed the select boxes in the tr:inputDate. We now just
>> noticed
>> that any select boxes that are on the page disappear whenever the
>> calendar lightweight dialog is displayed. I'd like to add the
>> ChooseRenderer.java to our sources to see if that fixes this new
>> problem.
>>
>> Thanks,
>>
>> Richard
>>
>> On Thu, Dec 4, 2008 at 6:12 AM, Manickam  wrote:
>>>
>>> Richard,
>>>
>>> Thanks for your response. We tried donwloading the Choose Renderer
>>> class
>>> from the patch and compiled the same and included into the Trinidad
>>> 1.10
>>> jar
>>> files but this did not resolve the issue.
>>>
>>> Please let us know how to include this ChooseRenderer.java path into
>>> our
>>> project.
>>>
>>> thanks,
>>> Kannappan
>>>
>>>
>>> Richard Yee-3 wrote:

 Gerhard,
 Are you using IE 6? What version of Trinidad are you using? This
 bug
 was reported back in May, 2008. It is pretty easy to reproduce.

 -Richard



 On Fri, Nov 14, 2008 at 12:29 PM, Gerhard Petracek
  wrote:
> hello,
>
> it works fine in my application. so it shouldn't be a general
> issue.
>
> regard