On Sun, 2008-02-17 at 08:16 +0100, Mario Ivankovits wrote:
If we find a way how these could work I wouldn't mind if we get rid of the
current solution.
Your wish is my command.
When thinking about it, this one wasn't possible with my solution either. So,
probably lets not put this
, 2008 9:08 am
Subject: Re: [orchestra] conversation-scoped converters
To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces
Development dev@myfaces.apache.org
On Sun, 2008-02-17 at 08:16 +0100, Mario Ivankovits wrote:
If we find a way how these could work I wouldn't mind if we get
On Sun, 2008-02-17 at 09:44 +0100, Mario Ivankovits wrote:
Sorry for top posting, the handy client makes it hard to make it right.
What you have done so far is great I think.
But there is a third way of configuring a converter.
This is configuring a converter with its own tag, like
Hi!
But there is a third way of configuring a converter.
This is configuring a converter with its own tag, like dateTimeConverter.
This allows you to configure this very instance of the converter.
We don't need to support pulling f:dateTimeConverter instances from
Spring do we? Those
Hi,
Currently in Orchestra a lot of effort goes into allowing this:
someComponent id=comp1 value=
f:converter id=convId/
/someComponent
where the actual converter instance attached to comp1 is pulled from
Spring.
In particular, this is AFAIK the only reason why class
Hi!
It *is* useful to be able to create converters that have access to
conversation scopes, which in turn mean they need to be instantiated by
pulling them from Spring. But this syntax is already supported by jsf:
someComponent id=comp2 converter=#{convId}/
I don't think so. Isnt it that the
Hi Mario,
Nice to see you back!
On Sat, 2008-02-16 at 16:37 +0100, Mario Ivankovits wrote:
Hi!
It *is* useful to be able to create converters that have access to
conversation scopes, which in turn mean they need to be instantiated by
pulling them from Spring. But this syntax is already
Hi!
Nice to see you back!
Hehe - Thanks! Yea, and in after-ski-mode now ;-)
Nope. The EL expression returns a Converter instance
ah - wasn't aware from top of my head.
Ok, so probably the ony thing we have to take a look at is how those converters
work installed as child of a component using
On Sat, 2008-02-16 at 18:10 +0100, Mario Ivankovits wrote:
Hi!
Nice to see you back!
Hehe - Thanks! Yea, and in after-ski-mode now ;-)
Go on, rub it in .. I've been spending all my spare time working on an
Orchestra release :-)
Nope. The EL expression returns a Converter instance
Hi!
Go on, rub it in .. I've been spending all my spare time working on an
Orchestra release :-)
That's fun too, isn't it ;-)
If we find a way how these could work I wouldn't mind if we get rid of the
current solution.
Your wish is my command.
When thinking about it, this one wasn't
=602459view=rev
Log:
fixed regression regarding viewController scope
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/AbstractSpringOrchestraScope.java
@@ -231,13 +231,11 @@
Object proxy =
beanDefinition.getAttribute
/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/spring/AbstractSpringOrchestraScope.java
@@ -231,13 +231,11 @@
Object proxy =
beanDefinition.getAttribute(ScopedBeanTargetSource.class.getName());
if (proxy == null
Hi!
I am trying to create a master-detail screen scenario and am following the
best-practices guide in the wiki (the simple CRUD cycle -
http://wiki.apache.org/myfaces/A_simple_Crud_Cycle) and it does not actually
work. Am I doing something wrong?
Unhappily the author of this page did not say
be
lost. For sure, this filter bean should not hold any entity as you might
run into problems if passing entities from one conversation to another
one.
Hope this helps!
Ciao,
Mario
--
View this message in context:
http://www.nabble.com/-orchestra--Conversation-issues-with-master-detail
in context:
http://www.nabble.com/-orchestra--Conversation-issues-with-master-detail-tf4894353.html#a14017094
Sent from the My Faces - Dev mailing list archive at Nabble.com.
autoConversation ?
and we stick w/ manualConversation, which says exactly what it does :)
On 11/7/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Matthias Wessendorf schrieb:
yes, but the term flash is used there differently, from what I heard.
So then, what is an appropriate term in the
Hi!
flash is somewhat confusing to persons that know rails...
Should we change the name(s)?
manualConversation
flashConversation
AFAIR in the documentation we already talk about conversation.manual and
conversation.flash.
Ciao,
Mario
Hi,
flash is somewhat confusing to persons that know rails...
Should we change the name(s)?
manualConversation
flashConversation
Perhaps we need just a better term for flash ?
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
Matthias Wessendorf schrieb:
yes, but the term flash is used there differently, from what I heard.
So then, what is an appropriate term in the JSF world?
---
Mario
yes, but the term flash is used there differently, from what I heard.
-M
On 11/7/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
flash is somewhat confusing to persons that know rails...
Should we change the name(s)?
manualConversation
flashConversation
AFAIR in the
Hi!
IMHO, a conversation should behave exactly the same as the session
does today - per default. There is nothing elementary different just
because you can have a multitude of conversations per user.
Getting in touch to the servlet timeout means we have to extend the
FrameworkAdapter
[EMAIL PROTECTED]
Date: Saturday, Sep 8, 2007 8:36 pm
Subject: Re: [orchestra] Conversation Timeouts (was changed scope
configuration)
To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces
Development dev@myfaces.apache.org
Ok, so I guess orchestra could use that same
Currently the config for a scope (from which a conversation inherits its
properties) looks like this:
bean class=...orchestra.spring.SpringConversationScope
property name=timeout value=30/
/bean
If no timeout property is present, then no timeout applies.
Otherwise, the specified
Hi!
If no timeout property is present, then no timeout applies.
Otherwise, the specified timeout applies.
You are right too with all you said.
Hmmm No pc here yet, but, how do a servlet container behave if there is no
session timeout configured or is it a required configuration?
Ciao,
Hello,
according to the Servlet specification:
///
The session-timeout element defines the default
session timeout interval for all sessions created
in this web application. The specified timeout
must be expressed in a whole number of minutes.
If the timeout is 0 or less, the container ensures
Ok, so I guess orchestra could use that same convention. This is still a
magic number that people will need to look up in the docs, though.
I still think it is more intuitive for people to not get a conversation
timeout unless they configure one. There will be absolutely no surprised
developers
-
From: simon [EMAIL PROTECTED]
Date: Saturday, Sep 8, 2007 8:36 pm
Subject: Re: [orchestra] Conversation Timeouts (was changed scope
configuration)
To: Reply-MyFaces Development dev@myfaces.apache.orgTo: MyFaces
Development dev@myfaces.apache.org
Ok, so I guess orchestra could use
Hi!
I made some changes to conserve resources regarding the
conversation-timeout-checking thread.
We had one thread per session which might become heavy-weight if you
have to deal with a lot of sessions.
Using a listener we are now able to drop down to just one thread per
context.
Those already
Hi!
Currently orchestra has a feature that causes conversations that have
not been accessed within 30 minutes to automatically be deleted.
Similarly, conversation-contexts that have not been accessed within 30
minutes also get deleted.
This came up [1] in relation to Shale dialogs [2],
Forwarded Message
From: simon [EMAIL PROTECTED]
To: MyFaces Development dev@myfaces.apache.org
Subject: Re: [orchestra] conversation timeouts
Date: Sat, 18 Aug 2007 13:07:29 +0200
On Sat, 2007-08-18 at 12:47 +0200, Mario Ivankovits wrote:
I briefly
considered having an app
Forwarded Message
From: simon [EMAIL PROTECTED]
To: MyFaces Development dev@myfaces.apache.org
Subject: Re: [orchestra] conversation timeouts
Date: Sat, 18 Aug 2007 13:35:07 +0200
On Sat, 2007-08-18 at 10:19 +0200, simon wrote:
The current implementation is for a Thread
Forwarded Message
From: simon [EMAIL PROTECTED]
To: MyFaces Development dev@myfaces.apache.org
Subject: Re: [orchestra] conversation timeouts
Date: Sat, 18 Aug 2007 18:44:19 +0200
Hi Adam,
Thanks for your comments.
Yes, hitchhiking on other requests would be great - if we
Hi!
One issue is that garbage collection only happens at some random time
after the session is no longer used. So the timeout thread could end up
calling into the ConversationManager even after the session has been
explicitly removed. Possibly the ConversationManager could implement
Hi All,
Currently orchestra has a feature that causes conversations that have
not been accessed within 30 minutes to automatically be deleted.
Similarly, conversation-contexts that have not been accessed within 30
minutes also get deleted.
I don't personally see the use of this, but have been
Hi!
Currently orchestra has a feature that causes conversations that have
not been accessed within 30 minutes to automatically be deleted.
Similarly, conversation-contexts that have not been accessed within 30
minutes also get deleted.
I don't personally see the use of this, but have been
Mostly ignorant of orchestra, but:
Could you hitchhike on other requests? On any request,
look through a conversation list, and any that haven't
been accessed within 30 minutes get deleted.
If no requests are coming in, then one really doesn't
care about excessive resource use. :)
Finding a way
On 8/18/07, simon [EMAIL PROTECTED] wrote:
Hi All,
Currently orchestra has a feature that causes conversations that have
not been accessed within 30 minutes to automatically be deleted.
Similarly, conversation-contexts that have not been accessed within 30
minutes also get deleted.
I don't
://svn.apache.org/viewvc?view=revrev=567017
Log:
Add javadoc only.
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra/conversation/jsf/filter/OrchestraServletFilter.java
Modified:
myfaces/orchestra/trunk/core/src/main/java/org/apache/myfaces/orchestra
38 matches
Mail list logo
