Problems with orchestra and JSF 2
Hi, I am having some troubles with orchestra maintaining some beans in conversation access scope. First, could someone explain me why the beans constructor is called multiple times? In my app I have multiple beans with the same conversation name and when I access one of the other beans from my bean, it seems as it is picking a new instance. The same scenario works fine using session beans, but of course then I lose all the nice transaction management from Orchestra. Anyone with an idea where I can I look? How is people dealing with JPA and transactions scoping multiple requests in JSF 2? I am having another issue as well. Even if I have one bean, the data seems not to be in the model when I click on a button that invokes a method in that bean. For this specific case, I have a f:metadata section with a viewParam. I can see the param being set in the update model phase, but the bean's existing data seems to be lost? For sure, I must be doing something wrong but I am unable to see what. Thanks! Bruno
Re: Problems with orchestra and JSF 2
Hi Bruno! First, could someone explain me why the beans constructor is called multiple times? What you see might be an effect of proxies. Usually if a subclassing proxy gets initialised, the constructor of the proxied class gets called. This is the reason why it's not suggested to use constructors for initialisations at all but instead use @PostConstruct (resp @PreDestroy instead of finalize) LieGrue, strub - Original Message From: brunoaranda brunoara...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Sent: Thu, July 1, 2010 12:55:30 PM Subject: Problems with orchestra and JSF 2 Hi, I am having some troubles with orchestra maintaining some beans in conversation access scope. First, could someone explain me why the beans constructor is called multiple times? In my app I have multiple beans with the same conversation name and when I access one of the other beans from my bean, it seems as it is picking a new instance. The same scenario works fine using session beans, but of course then I lose all the nice transaction management from Orchestra. Anyone with an idea where I can I look? How is people dealing with JPA and transactions scoping multiple requests in JSF 2? I am having another issue as well. Even if I have one bean, the data seems not to be in the model when I click on a button that invokes a method in that bean. For this specific case, I have a f:metadata section with a viewParam. I can see the param being set in the update model phase, but the bean's existing data seems to be lost? For sure, I must be doing something wrong but I am unable to see what. Thanks! Bruno
Re: Problems with orchestra and JSF 2
I see, yes, that could explain it as Spring is creating proxies all over the place to make some of the annotations work. However I am not doing anything in the constructors, but for instance, if I set a property on a backing bean (conversation.access scope), when I click on a button that value seems to have been lost, as if I was accessing another object... probably something to do with proxies as well and orchestra? Thanks! Bruno On 1 July 2010 13:22, Mark Struberg strub...@yahoo.de wrote: Hi Bruno! First, could someone explain me why the beans constructor is called multiple times? What you see might be an effect of proxies. Usually if a subclassing proxy gets initialised, the constructor of the proxied class gets called. This is the reason why it's not suggested to use constructors for initialisations at all but instead use @PostConstruct (resp @PreDestroy instead of finalize) LieGrue, strub - Original Message From: brunoaranda brunoara...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Sent: Thu, July 1, 2010 12:55:30 PM Subject: Problems with orchestra and JSF 2 Hi, I am having some troubles with orchestra maintaining some beans in conversation access scope. First, could someone explain me why the beans constructor is called multiple times? In my app I have multiple beans with the same conversation name and when I access one of the other beans from my bean, it seems as it is picking a new instance. The same scenario works fine using session beans, but of course then I lose all the nice transaction management from Orchestra. Anyone with an idea where I can I look? How is people dealing with JPA and transactions scoping multiple requests in JSF 2? I am having another issue as well. Even if I have one bean, the data seems not to be in the model when I click on a button that invokes a method in that bean. For this specific case, I have a f:metadata section with a viewParam. I can see the param being set in the update model phase, but the bean's existing data seems to be lost? For sure, I must be doing something wrong but I am unable to see what. Thanks! Bruno
Re: Problems with orchestra and JSF 2
What I can see as well after putting a method with the @PostConstruct
annotation, is that this method is called every request, as if the
conversation didn't exist before, which is not true.
I am outputting the orchestra logs in the console, and I can see:
2010-07-01 14:05:32,729 [qtp33228489-20] DEBUG (DebugPhaseListener,40) -
Before phase: RESTORE_VIEW(1)
2010-07-01 14:05:32,823 [qtp33228489-20] DEBUG (Conversation,108) - start
conversation:general
NEW INSTANCE PUBCONTROLLER HASH: 9f720d
POST CONS PUB === 9f720d
NEW INSTANCE PUBCONTROLLER HASH: 147f75
NEW INSTANCE PUBCONTROLLER HASH: 1bbefe8
2010-07-01 14:05:32,844 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:org.springframework.beans.factory.support.Dispo
sablebeanadap...@25394361
(bean=org.apache.myfaces.orchestra.conversation.spring.abstractspringorchestrascop...@17167e6
)
2010-07-01 14:05:32,846 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:org.apache.myfaces.orchestra.conversation.sprin
g.PersistenceContextConversationInterceptor.PERSISTENCE_CONTEXT(bean=org.apache.myfaces.orchestra.conversation.spring.PersistenceContextClos
e...@81f22c)
2010-07-01 14:05:32,847 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:publicationController(bean=uk.ac.ebi.intact.edi
tor.controller.curate.publication.publicationcontrol...@9f720d)
2010-07-01 14:05:32,853 [qtp33228489-20] DEBUG (DebugPhaseListener,35) -
After phase: RESTORE_VIEW(1)
...
The bean is called publicationController, which should be maintained in a
conversation called general. And I see this every request. This is the
bean class annotations:
@Controller
@Scope( conversation.access )
@ConversationName( general )
public class PublicationController extends AnnotatedObjectController {
...}
I fail to see why the bean is not re-used as the conversation is not ended.
And then, if I let the conversation expire, I see the message as many times
as instances have been created (three requests in my case to the same
page...).
2010-07-01 14:39:28,563 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,565 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,566 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
So I am not sure what is happening here :(
Bruno
On 1 July 2010 13:27, Bruno Aranda brunoara...@gmail.com wrote:
I see, yes, that could explain it as Spring is creating proxies all over
the place to make some of the annotations work. However I am not doing
anything in the constructors, but for instance, if I set a property on a
backing bean (conversation.access scope), when I click on a button that
value seems to have been lost, as if I was accessing another object...
probably something to do with proxies as well and orchestra?
Thanks!
Bruno
On 1 July 2010 13:22, Mark Struberg strub...@yahoo.de wrote:
Hi Bruno!
First, could someone explain me why the
beans constructor
is called multiple times?
What you see might be an effect of proxies.
Usually if a subclassing proxy gets initialised, the constructor of the
proxied class gets called.
This is the reason why it's not suggested to use constructors for
initialisations at all but instead use
@PostConstruct (resp @PreDestroy instead of finalize)
LieGrue,
strub
- Original Message
From: brunoaranda brunoara...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Sent: Thu, July 1, 2010 12:55:30 PM
Subject: Problems with orchestra and JSF 2
Hi,
I am having some troubles with orchestra maintaining some beans
in
conversation access scope. First, could someone explain me why the
beans
constructor is called multiple times? In my app I have multiple beans
with
the same conversation name and when I access one of the other beans from
my
bean, it seems as it is picking a new instance. The same scenario works
fine
using session beans, but of course then I lose all the nice
transaction
management from Orchestra. Anyone with an idea where I can I
look? How is
people dealing with JPA and transactions scoping multiple
requests in JSF 2?
I am having another issue as well. Even if I have one
bean, the data seems
not to be in the model when I click on a button that
invokes a method in
that bean. For this specific case, I have a
f:metadata section with a
viewParam. I can see the param being set in
the update model phase, but the
bean's existing data seems to be lost? For
sure, I must be doing something
wrong but I am unable to see
what.
Thanks!
Bruno
Long transactions
Hi, Is anyone here using long JPA transactions in their applications (transactions that span more than one request) but not using Orchestra?. How are you doing it? Cheers, Bruno
ExtVal: Validating an objects attributes if at least one these has a value
Hi at all,
I have the following use case simplified with an object 'Address' including
zip, city and so on using BeanValidation:
public class Address {
@NotNull(Create.class)
@Size(min=3, max=10)
private String zip;
@NotNull
@Size(min=3, max=50)
private String city;
...
}
This class should be used in two pages: for creating an address (both
attributes need to be set, group=Create) and to find an address (city is
sufficient for searching, group=default).
In addition I want to reuse the address definition in pages to submit or search
an order with both a home address and an optional invoice address. The problem
is: if no value is entered into the fields for the invoice address, it should
not be validated at all. If at least one field is filled, all constraints have
to be validated, additionally considering groups to be used.
I think with bean validation only this is not possible, that's why I guess I
have to use ExtVal again but don't know where to start. A custom validation
strategy would be a choice, perhaps @SkipValidation offers another way to go?
Or can it be done even easier (settings remain unchanged: single class as
central point for validation rules which is reusabe in different use cases,
validation should take place in validation phase)?
Can you give me some advice where to start?
Thanks,
Tom
--
Hotelbewertung: Bloß nicht die Katze im Sack kaufen bzw. den Floh auf der
Matratze buchen -
ob geschäftlich oder privat - erst das Hotel im Reise-Channel auf arcor.de
checken!
http://www.arcor.de/rd/footer.hotel
Re: Problems with orchestra and JSF 2
Heya!
Please check the url parameter conversationContext has been added to each
and every url.
If it is missing, a new context will be created each request and then a new
bean will be created too.
Now you sure would like to know why it is missing ... if it is missing.
Hmmm ... do you use portlets or such?
Ciao,
Mario
PS: Sorry for top-posting, Mail-Client oddities ... :)
-Ursprüngliche Nachricht-
Von: Bruno Aranda [mailto:brunoara...@gmail.com]
Gesendet: Donnerstag, 01. Juli 2010 14:42
An: MyFaces Discussion
Betreff: Re: Problems with orchestra and JSF 2
What I can see as well after putting a method with the @PostConstruct
annotation, is that this method is called every request, as if the
conversation didn't exist before, which is not true.
I am outputting the orchestra logs in the console, and I can see:
2010-07-01 14:05:32,729 [qtp33228489-20] DEBUG (DebugPhaseListener,40) -
Before phase: RESTORE_VIEW(1)
2010-07-01 14:05:32,823 [qtp33228489-20] DEBUG (Conversation,108) - start
conversation:general
NEW INSTANCE PUBCONTROLLER HASH: 9f720d
POST CONS PUB === 9f720d
NEW INSTANCE PUBCONTROLLER HASH: 147f75
NEW INSTANCE PUBCONTROLLER HASH: 1bbefe8
2010-07-01 14:05:32,844 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:org.springframework.beans.factory.support.Dispo
sablebeanadap...@25394361
(bean=org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchest
rascop...@17167e6
)
2010-07-01 14:05:32,846 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:org.apache.myfaces.orchestra.conversation.sprin
g.PersistenceContextConversationInterceptor.PERSISTENCE_CONTEXT(bean=org.apa
che.myfaces.orchestra.conversation.spring.PersistenceContextClos
e...@81f22c)
2010-07-01 14:05:32,847 [qtp33228489-20] DEBUG (Conversation,176) - put bean
to conversation:publicationController(bean=uk.ac.ebi.intact.edi
tor.controller.curate.publication.publicationcontrol...@9f720d)
2010-07-01 14:05:32,853 [qtp33228489-20] DEBUG (DebugPhaseListener,35) -
After phase: RESTORE_VIEW(1)
...
The bean is called publicationController, which should be maintained in a
conversation called general. And I see this every request. This is the
bean class annotations:
@Controller
@Scope( conversation.access )
@ConversationName( general )
public class PublicationController extends AnnotatedObjectController {
...}
I fail to see why the bean is not re-used as the conversation is not ended.
And then, if I let the conversation expire, I see the message as many times
as instances have been created (three requests in my case to the same
page...).
2010-07-01 14:39:28,563 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,565 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,566 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
So I am not sure what is happening here :(
Bruno
On 1 July 2010 13:27, Bruno Aranda brunoara...@gmail.com wrote:
I see, yes, that could explain it as Spring is creating proxies all over
the place to make some of the annotations work. However I am not doing
anything in the constructors, but for instance, if I set a property on a
backing bean (conversation.access scope), when I click on a button that
value seems to have been lost, as if I was accessing another object...
probably something to do with proxies as well and orchestra?
Thanks!
Bruno
On 1 July 2010 13:22, Mark Struberg strub...@yahoo.de wrote:
Hi Bruno!
First, could someone explain me why the
beans constructor
is called multiple times?
What you see might be an effect of proxies.
Usually if a subclassing proxy gets initialised, the constructor of the
proxied class gets called.
This is the reason why it's not suggested to use constructors for
initialisations at all but instead use
@PostConstruct (resp @PreDestroy instead of finalize)
LieGrue,
strub
- Original Message
From: brunoaranda brunoara...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Sent: Thu, July 1, 2010 12:55:30 PM
Subject: Problems with orchestra and JSF 2
Hi,
I am having some troubles with orchestra maintaining some beans
in
conversation access scope. First, could someone explain me why the
beans
constructor is called multiple times? In my app I have multiple beans
with
the same conversation name and when I access one of the other beans from
my
bean, it seems as it is picking a new instance. The same scenario works
fine
using session beans, but of course then I lose all the nice
transaction
management from Orchestra. Anyone with an idea where I can I
look? How is
people dealing with JPA and transactions scoping multiple
requests in JSF 2?
I am having another issue as well. Even if I have one
bean, the data seems
not to be in the model when I click on a button that
invokes a
Re: ExtVal: Validating an objects attributes if at least one these has a value
hi tom,
in this special case the usage of @SkipValidation wouldn't lead to a nice
solution.
in case of bv + extval: there is a new add-on [1] for bv based
multi-field-validation.
however, also with this new prototype you would need group-validation (for
this special case) to bypass the constraints hosted at the targets of the
value-bindings.
regards,
gerhard
[1]
http://os890.blogspot.com/2010/06/multi-field-form-validation-with-jsr.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/1 mynewsgro...@arcor.de
Hi at all,
I have the following use case simplified with an object 'Address' including
zip, city and so on using BeanValidation:
public class Address {
@NotNull(Create.class)
@Size(min=3, max=10)
private String zip;
@NotNull
@Size(min=3, max=50)
private String city;
...
}
This class should be used in two pages: for creating an address (both
attributes need to be set, group=Create) and to find an address (city is
sufficient for searching, group=default).
In addition I want to reuse the address definition in pages to submit or
search an order with both a home address and an optional invoice address.
The problem is: if no value is entered into the fields for the invoice
address, it should not be validated at all. If at least one field is filled,
all constraints have to be validated, additionally considering groups to be
used.
I think with bean validation only this is not possible, that's why I guess
I have to use ExtVal again but don't know where to start. A custom
validation strategy would be a choice, perhaps @SkipValidation offers
another way to go? Or can it be done even easier (settings remain unchanged:
single class as central point for validation rules which is reusabe in
different use cases, validation should take place in validation phase)?
Can you give me some advice where to start?
Thanks,
Tom
--
Hotelbewertung: Bloß nicht die Katze im Sack kaufen bzw. den Floh auf der
Matratze buchen -
ob geschäftlich oder privat - erst das Hotel im Reise-Channel auf
arcor.dechecken!
http://www.arcor.de/rd/footer.hotel
Re: Problems with orchestra and JSF 2
Hi,
No I do not use portlets. I am now writing a simple test case, to see if I
can reproduce it. With the simplest case, everything is working as expected,
so there has to be some conflict with the rest of the application (e.g.
Spring 3 proxies, the transaction manager or something else). I am
investigating to see if I can reproduce it...
The conversationContext is fine in both scenarios...
Bruno
On 1 July 2010 16:50, Mario Ivankovits ma...@ops.co.at wrote:
Heya!
Please check the url parameter conversationContext has been added to each
and every url.
If it is missing, a new context will be created each request and then a new
bean will be created too.
Now you sure would like to know why it is missing ... if it is missing.
Hmmm ... do you use portlets or such?
Ciao,
Mario
PS: Sorry for top-posting, Mail-Client oddities ... :)
-Ursprüngliche Nachricht-
Von: Bruno Aranda [mailto:brunoara...@gmail.com]
Gesendet: Donnerstag, 01. Juli 2010 14:42
An: MyFaces Discussion
Betreff: Re: Problems with orchestra and JSF 2
What I can see as well after putting a method with the @PostConstruct
annotation, is that this method is called every request, as if the
conversation didn't exist before, which is not true.
I am outputting the orchestra logs in the console, and I can see:
2010-07-01 14:05:32,729 [qtp33228489-20] DEBUG (DebugPhaseListener,40) -
Before phase: RESTORE_VIEW(1)
2010-07-01 14:05:32,823 [qtp33228489-20] DEBUG (Conversation,108) - start
conversation:general
NEW INSTANCE PUBCONTROLLER HASH: 9f720d
POST CONS PUB === 9f720d
NEW INSTANCE PUBCONTROLLER HASH: 147f75
NEW INSTANCE PUBCONTROLLER HASH: 1bbefe8
2010-07-01 14:05:32,844 [qtp33228489-20] DEBUG (Conversation,176) - put
bean
to conversation:org.springframework.beans.factory.support.Dispo
sablebeanadap...@25394361
(bean=org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchest
rascop...@17167e6
)
2010-07-01 14:05:32,846 [qtp33228489-20] DEBUG (Conversation,176) - put
bean
to conversation:org.apache.myfaces.orchestra.conversation.sprin
g.PersistenceContextConversationInterceptor.PERSISTENCE_CONTEXT(bean=org.apa
che.myfaces.orchestra.conversation.spring.PersistenceContextClos
e...@81f22c)
2010-07-01 14:05:32,847 [qtp33228489-20] DEBUG (Conversation,176) - put
bean
to conversation:publicationController(bean=uk.ac.ebi.intact.edi
tor.controller.curate.publication.publicationcontrol...@9f720d)
2010-07-01 14:05:32,853 [qtp33228489-20] DEBUG (DebugPhaseListener,35) -
After phase: RESTORE_VIEW(1)
...
The bean is called publicationController, which should be maintained in a
conversation called general. And I see this every request. This is the
bean class annotations:
@Controller
@Scope( conversation.access )
@ConversationName( general )
public class PublicationController extends AnnotatedObjectController {
...}
I fail to see why the bean is not re-used as the conversation is not ended.
And then, if I let the conversation expire, I see the message as many times
as instances have been created (three requests in my case to the same
page...).
2010-07-01 14:39:28,563 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,565 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
2010-07-01 14:39:28,566 [Orchestra:ConversationWiperThread] DEBUG
(Conversation,311) - destroy conversation:general
So I am not sure what is happening here :(
Bruno
On 1 July 2010 13:27, Bruno Aranda brunoara...@gmail.com wrote:
I see, yes, that could explain it as Spring is creating proxies all over
the place to make some of the annotations work. However I am not doing
anything in the constructors, but for instance, if I set a property on a
backing bean (conversation.access scope), when I click on a button that
value seems to have been lost, as if I was accessing another object...
probably something to do with proxies as well and orchestra?
Thanks!
Bruno
On 1 July 2010 13:22, Mark Struberg strub...@yahoo.de wrote:
Hi Bruno!
First, could someone explain me why the
beans constructor
is called multiple times?
What you see might be an effect of proxies.
Usually if a subclassing proxy gets initialised, the constructor of the
proxied class gets called.
This is the reason why it's not suggested to use constructors for
initialisations at all but instead use
@PostConstruct (resp @PreDestroy instead of finalize)
LieGrue,
strub
- Original Message
From: brunoaranda brunoara...@gmail.com
To: MyFaces Discussion users@myfaces.apache.org
Sent: Thu, July 1, 2010 12:55:30 PM
Subject: Problems with orchestra and JSF 2
Hi,
I am having some troubles with orchestra maintaining some beans
in
conversation access scope. First, could someone explain me why the
beans
constructor is called multiple times?
Trinidad PortletBridge buttons don't work fine
Hi at all,
I have this view and this methods in controller , all is fine in servlet
mode but in portlet mode:
- the locale is not immedialty rendered (next page is ok)
- the reset change also the locale (in en where i am in fr)
without sense for me.
---
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://myfaces.apache.org/trinidad; prefix=tr%
%@ taglib uri=http://myfaces.apache.org/trinidad/html; prefix=trh%
f:view locale=#{commonController.locale}
f:loadBundle basename=MessageResources var=msg /
tr:document title=#{msg['DIRECTORY.TEXT']}
f:facet name=metaContainer
link rel=apple-touch-icon href=images/touchicon.png
meta name=viewport content=initial-scale=1.0,
maximum-scale=1.0, user-scalable=0 /
link href=./minimal/minimal.css rel=stylesheet
type=text/css /
/f:facet
tr:form id=home
tr:panelHeader id=panelHeader styleClass=toolbar
text=#{msg['DIRECTORY.TEXT']}
tr:commandLink id=reset styleClass=resetButton
text=#{msg['CANCEL.TEXT']}
actionListener=#{commonController.reset} /
tr:commandLink styleClass=loginButton action=login
rendered=#{not commonController.userAuthenticated
and not commonController.portletMode}
immediate=true /
tr:commandLink styleClass=logoutButton
actionListener=#{commonController.logout}
rendered=#{commonController.userAuthenticated and
not commonController.portletMode}
immediate=true /
tr:commandLink id=fr styleClass=frButton
actionListener=#{commonController.setLocaleFrench}
immediate=true /
tr:commandLink id=en styleClass=enButton
actionListener=#{commonController.setLocaleEnglish} immediate=true /
/tr:panelHeader
tr:outputText styleClass=user value=#{msg['USER.TEXT']}
#{commonController.user}
rendered=#{commonController.userAuthenticated and not
commonController.portletMode} /
tr:panelList styleClass=panelList
tr:inputText id=name value=#{commonController.name}
required=true label=
f:validator validatorId=nameValidator /
/tr:inputText
tr:commandLink text=#{msg['STAFF.TEXT']}
action=persons /
tr:commandLink text=#{msg['STUDENTS.TEXT']}
action=students
rendered=#{commonController.userAuthenticated} /
tr:commandLink text=#{msg['ENTITIES.TEXT']}
action=entities /
tr:goLink text=#{msg['FACULTY_WEB_PAGE.TEXT']}
destination=#{commonController.facultyWebPageUrl} /
/tr:panelList
/tr:form
/tr:document
/f:view
-
/**
* @param actionEvent
* @return navigation String.
*/
public String setLocaleFrench(ActionEvent actionEvent) {
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().setLocale(new Locale(fr));
locale = fr;
logger.info(Language: fr);
return home;
}
/**
* @param actionEvent
* @return navigation String.
*/
public String setLocaleEnglish(ActionEvent actionEvent) {
FacesContext context = FacesContext.getCurrentInstance();
context.getViewRoot().setLocale(new Locale(en));
locale = en;
logger.info(Language: en);
return home;
}
/**
* @return the locale
*/
public String getLocale() {
return locale;
}
/**
* @param actionEvent
* @return navigation String.
*/
public String reset(ActionEvent actionEvent) {
name = null;
logger.info(Action: reset);
return home;
}
--
Yves Deschamps
CRI Pôle Web, Environnement Numérique de Travail
Bâtiment M4
Tel : 03 20 43 41 89
Fax : 03 20 43 66 25
Set values to t:selectManyPicklist
Hi,
I am trying to set the values of the t:selectManyPicklist
t:selectManyPicklist value=#{user.selectedList}
addButtonStyleClass=button addAllButtonStyle=true
style=width:350px size=10
f:selectItems value=#{user.availableList} /
/t:selectManyPicklist
But the other list is not populated. I also do not get the Button Style
working.
I have seen one example in the forums which was s:selectManyPicklist.
I am little confused. Did anyone have done this with Myfaces 1.2?
Thanks
Vinaya
This electronic message is intended only for the use of the individual(s) or
entity(ies) named above and may contain information which is privileged and/or
confidential. If you are not the intended recipient, be aware that any
disclosure, copying, distribution, dissemination or use of the contents of this
message is prohibited. If you received this message in error, please notify
the sender immediately.
Re: Trinidad PortletBridge buttons don't work fine
I wonder if this problem is the same as PORTLETBRIDGE-100
https://issues.apache.org/jira/browse/PORTLETBRIDGE-100
(https://issues.apache.org/jira/browse/PORTLETBRIDGE-100):
The first page of the JSF sample CarDemo has you set the locale for
the demo. You choose a language/region and the rest of the views use
strings earmarked for the language of the locale. In the portlet
case this fails -- you always use the English/default locale. This
is because the demo relies on an ActionHandler to set the locale of
the ViewRoot of the current view -- which subsequently is migrated
(by Faces) during the createView of the view the action handler
navigates to. When you render the subsequent view it uses this
locale. In the portlet case because render happens in a separate
request -- we rely on the bridge to cache the viewroot from the end
of the action and preset set it as the current viewRoot prior to
running the lifecycle. Well Faces has code in its restoreView phase
that if the ViewRoot was preset then it resets its locale to the
preferred one from the current request. I.e. we lose the locale we
wanted (that was set when the view was created at the end of the
action). To fix this, cache the locale in the beforePhase (of
restoreView) if using the preset ViewRoot and restore it in the
afterPhase.
What version of the bridge are you using? If P1.0B and its beta (or
before) then the above bug exists (or P2.0B alpha and before). Anyway,
I would suggest retrying with a new(er) bridge. Either build from the
trunk, wait a few days as we are in the processing of pushing the 1.0.0
release, or grab what we are pushing from our staged artifacts at:
http://people.apache.org/~mfreedman/portlet-bridge/
Let me know if this fixes it. If it doesn't please log a JIRA which
includes additional information describing the appserver and portal
server/container you are using, specific version information for all,
and (if possible) a small sample JSF app I can portletize so I can
deploy locally and debug.
-Mike-
On 7/1/2010 8:37 AM, Yves Deschamps wrote:
Hi at all,
I have this view and this methods in controller , all is fine in
servlet mode but in portlet mode:
- the locale is not immedialty rendered (next page is ok)
- the reset change also the locale (in en where i am in fr)
without sense for me.
---
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://myfaces.apache.org/trinidad; prefix=tr%
%@ taglib uri=http://myfaces.apache.org/trinidad/html; prefix=trh%
f:view locale=#{commonController.locale}
f:loadBundle basename=MessageResources var=msg /
tr:document title=#{msg['DIRECTORY.TEXT']}
f:facet name=metaContainer
link rel=apple-touch-icon href=images/touchicon.png
meta name=viewport content=initial-scale=1.0,
maximum-scale=1.0, user-scalable=0 /
link href=./minimal/minimal.css rel=stylesheet
type=text/css /
/f:facet
tr:form id=home
tr:panelHeader id=panelHeader styleClass=toolbar
text=#{msg['DIRECTORY.TEXT']}
tr:commandLink id=reset styleClass=resetButton
text=#{msg['CANCEL.TEXT']}
actionListener=#{commonController.reset} /
tr:commandLink styleClass=loginButton action=login
rendered=#{not commonController.userAuthenticated
and not commonController.portletMode}
immediate=true /
tr:commandLink styleClass=logoutButton
actionListener=#{commonController.logout}
rendered=#{commonController.userAuthenticated and
not commonController.portletMode}
immediate=true /
tr:commandLink id=fr styleClass=frButton
actionListener=#{commonController.setLocaleFrench} immediate=true /
tr:commandLink id=en styleClass=enButton
actionListener=#{commonController.setLocaleEnglish} immediate=true /
/tr:panelHeader
tr:outputText styleClass=user value=#{msg['USER.TEXT']}
#{commonController.user}
rendered=#{commonController.userAuthenticated and not
commonController.portletMode} /
tr:panelList styleClass=panelList
tr:inputText id=name
value=#{commonController.name} required=true label=
f:validator validatorId=nameValidator /
/tr:inputText
tr:commandLink text=#{msg['STAFF.TEXT']}
action=persons /
tr:commandLink text=#{msg['STUDENTS.TEXT']}
action=students
rendered=#{commonController.userAuthenticated} /
tr:commandLink text=#{msg['ENTITIES.TEXT']}
action=entities /
tr:goLink text=#{msg['FACULTY_WEB_PAGE.TEXT']}
Re: Long transactions
I am, sort of.
You really can't leave the transaction open beyond the request
response as it may never complete.
Some of the ways you can deal with it are:
1) work with fake holder entities that get changed back into real
entities at the final commit. Very ugly -- tried this one at first,
but I don't use it anymore.
2) Work with detached objects. Reattach them back right before the
final commit. This is what I currently do.I basically invented a
Unit-Of-Work framework that runs over the top of JPA.The unit of
work has a separate persistence manager that loads an object, then
immediately detaches it. Our framework requires each object to call
save() to commit changes. When in the UoW, all save does is add the
object to a change-tracker (inserts, deletes, updates).Then when
the UoW is committed, the objects are persisted or merged, then
committed all in one method call.
But in all honesty, this approach also has caused us a lot of hassles.
We are most likely going to dump JPA and replace it with Apache
Cayenne, which uses a real unit of work concept.
Another option for you might be to use an implementation-specific unit
of work provided by your JPA implementation. However, I don't know
if you might have other issues. I used Cayenne before I used JPA,
and I know Cayenne does exactly what I need.
A third option you could consider if you want to risk leaving the
transaction open.
a) Catch the window onunload event, and mixed with ajax, send an ajax
request when the user improperly attempts to leave the page (closes
the window or browser, enters a url directly, back buttons, some other
non-transaction-friendly link clicked).
I got this far with that approach, but didn't pursue it. Note that
this can only detect when the user is about to leave the page. It
cannot do anything at that point -- you'd have to do something about
it in some other way.
window.onbeforeunload = confirmExit;
function confirmExit()
{
if (needToConfirm)
return You have attempted to leave this page. If you
have
made any changes to the fields without clicking the Save button, your
changes will be lost. Are you sure you want to exit this page?;
}
b) Some other kind of client-side state tracking so that you know when
the user has navigated away from the current multi-request task.
We're sticking a taskGroupIdentifier field on every form (ajax
included) so we know when the user does something to switch to a new
task than the one we're currently working with. Doesn't help if you
have some transaction left open and the user never hits the web server
again, but a timeout could deal with that.
In short, I think it's a difficult problem, and I think JPA is
incapable of dealing with it correctly. The other shortfall we have
is that JPA cannot rollback a transaction. You have no way of
knowing what state your application is in once you roll back the
transaction. Again Cayenne automatically puts everything exactly
where it was at the start of your unit of work if you do a rollback.
On Thu, Jul 1, 2010 at 9:53 AM, Bruno Aranda brunoara...@gmail.com wrote:
Hi,
Is anyone here using long JPA transactions in their applications
(transactions that span more than one request) but not using Orchestra?. How
are you doing it?
Cheers,
Bruno
