Re: Problems with orchestra and JSF 2
I see, maybe we could just add some kind of warning, because the side
effects are confusing and it is difficult to know where is the problem?
Bruno
On 2 July 2010 22:03, Martin Koci martin.k...@aura.cz wrote:
Hi,
I have same problem with CDI a it's conversation.
Please see my comment on
https://issues.apache.org/jira/browse/MYFACES-2688
Best regards,
Martin Kočí
Leonardo Uribe píše v Pá 02. 07. 2010 v 13:31 -0500:
Hi
It is not a problem related to orchestra. JSF implementation does not
decode
request with enctype=multipart/form-data. Other user reported this on:
https://issues.apache.org/jira/browse/MYFACES-2688
For decode that kind of requests it is necessary to use a filter or a
FacesContextWrapper. Tomahawk is one option (using ExtensionFilter or
TomahawkFacesContextWrapper), but Trinidad and other jsf libraries
usually
has filters that do that.
regards,
Leonardo Uribe
2010/7/2 Bruno Aranda brunoara...@gmail.com
Hi! I have finally manager to create a very simple test case for my
problem.
My issue with data loss seems to be related to the enctype of the form
(multipart/form-data) and the fact that I am loading data using a
preRenderView event.
To reproduce this problem, create a test page:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
f:view contentType=text/html
h:body
h:form prependId=false enctype=multipart/form-data
f:metadata
f:event type=preRenderView
listener=#{playgroundController.load}/
/f:metadata
h:inputText value=#{playgroundController.car.colour}/
h:inputText value=#{playgroundController.car.make}/
h:outputText value=#{playgroundController.car}/
h:commandButton value=Talk
actionListener=#{playgroundController.talk}/
/h:form
/h:body
/f:view
/html
With a backing bean behind:
@Controller
@Scope( conversation.access )
public class PlaygroundController implements Serializable {
private Car car;
public PlaygroundController() {
System.out.println(\nNEW PLAY INSTANCE
+Integer.toHexString(hashCode())+\n);
}
public void load() {
System.out.println(\nLOAD
+Integer.toHexString(hashCode())+\n);
car = new Car();
}
public void talk(ActionEvent evt) {
System.out.println(CAR: +car);
}
public Car getCar() {
return car;
}
public void setCar(Car car) {
this.car = car;
}
}
If the enctype is multipart/form-data, when I click on the submit
button,
the bean will be instantiated again and the load method won't be
called...
throwing an ugly exception. If the enctype is the default, everything
works
as expected and the method talk(ActionEvent evt) will print the car
in
the
console as expected.
I am using multipart/form-data because I wanted to upload some files. I
can
see it is troublesome... anyone could explain me why?
Thanks!
Bruno
On 1 July 2010 17:09, Bruno Aranda brunoara...@gmail.com wrote:
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
Re: Problems with orchestra and JSF 2
Hi! I have finally manager to create a very simple test case for my problem.
My issue with data loss seems to be related to the enctype of the form
(multipart/form-data) and the fact that I am loading data using a
preRenderView event.
To reproduce this problem, create a test page:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
f:view contentType=text/html
h:body
h:form prependId=false enctype=multipart/form-data
f:metadata
f:event type=preRenderView
listener=#{playgroundController.load}/
/f:metadata
h:inputText value=#{playgroundController.car.colour}/
h:inputText value=#{playgroundController.car.make}/
h:outputText value=#{playgroundController.car}/
h:commandButton value=Talk
actionListener=#{playgroundController.talk}/
/h:form
/h:body
/f:view
/html
With a backing bean behind:
@Controller
@Scope( conversation.access )
public class PlaygroundController implements Serializable {
private Car car;
public PlaygroundController() {
System.out.println(\nNEW PLAY INSTANCE
+Integer.toHexString(hashCode())+\n);
}
public void load() {
System.out.println(\nLOAD +Integer.toHexString(hashCode())+\n);
car = new Car();
}
public void talk(ActionEvent evt) {
System.out.println(CAR: +car);
}
public Car getCar() {
return car;
}
public void setCar(Car car) {
this.car = car;
}
}
If the enctype is multipart/form-data, when I click on the submit button,
the bean will be instantiated again and the load method won't be called...
throwing an ugly exception. If the enctype is the default, everything works
as expected and the method talk(ActionEvent evt) will print the car in the
console as expected.
I am using multipart/form-data because I wanted to upload some files. I can
see it is troublesome... anyone could explain me why?
Thanks!
Bruno
On 1 July 2010 17:09, Bruno Aranda brunoara...@gmail.com wrote:
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
Re: Problems with orchestra and JSF 2
Hi
It is not a problem related to orchestra. JSF implementation does not decode
request with enctype=multipart/form-data. Other user reported this on:
https://issues.apache.org/jira/browse/MYFACES-2688
For decode that kind of requests it is necessary to use a filter or a
FacesContextWrapper. Tomahawk is one option (using ExtensionFilter or
TomahawkFacesContextWrapper), but Trinidad and other jsf libraries usually
has filters that do that.
regards,
Leonardo Uribe
2010/7/2 Bruno Aranda brunoara...@gmail.com
Hi! I have finally manager to create a very simple test case for my
problem.
My issue with data loss seems to be related to the enctype of the form
(multipart/form-data) and the fact that I am loading data using a
preRenderView event.
To reproduce this problem, create a test page:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
f:view contentType=text/html
h:body
h:form prependId=false enctype=multipart/form-data
f:metadata
f:event type=preRenderView
listener=#{playgroundController.load}/
/f:metadata
h:inputText value=#{playgroundController.car.colour}/
h:inputText value=#{playgroundController.car.make}/
h:outputText value=#{playgroundController.car}/
h:commandButton value=Talk
actionListener=#{playgroundController.talk}/
/h:form
/h:body
/f:view
/html
With a backing bean behind:
@Controller
@Scope( conversation.access )
public class PlaygroundController implements Serializable {
private Car car;
public PlaygroundController() {
System.out.println(\nNEW PLAY INSTANCE
+Integer.toHexString(hashCode())+\n);
}
public void load() {
System.out.println(\nLOAD +Integer.toHexString(hashCode())+\n);
car = new Car();
}
public void talk(ActionEvent evt) {
System.out.println(CAR: +car);
}
public Car getCar() {
return car;
}
public void setCar(Car car) {
this.car = car;
}
}
If the enctype is multipart/form-data, when I click on the submit button,
the bean will be instantiated again and the load method won't be called...
throwing an ugly exception. If the enctype is the default, everything works
as expected and the method talk(ActionEvent evt) will print the car in
the
console as expected.
I am using multipart/form-data because I wanted to upload some files. I can
see it is troublesome... anyone could explain me why?
Thanks!
Bruno
On 1 July 2010 17:09, Bruno Aranda brunoara...@gmail.com wrote:
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
Re: Problems with orchestra and JSF 2
Hi,
I have same problem with CDI a it's conversation.
Please see my comment on
https://issues.apache.org/jira/browse/MYFACES-2688
Best regards,
Martin Kočí
Leonardo Uribe píše v Pá 02. 07. 2010 v 13:31 -0500:
Hi
It is not a problem related to orchestra. JSF implementation does not decode
request with enctype=multipart/form-data. Other user reported this on:
https://issues.apache.org/jira/browse/MYFACES-2688
For decode that kind of requests it is necessary to use a filter or a
FacesContextWrapper. Tomahawk is one option (using ExtensionFilter or
TomahawkFacesContextWrapper), but Trinidad and other jsf libraries usually
has filters that do that.
regards,
Leonardo Uribe
2010/7/2 Bruno Aranda brunoara...@gmail.com
Hi! I have finally manager to create a very simple test case for my
problem.
My issue with data loss seems to be related to the enctype of the form
(multipart/form-data) and the fact that I am loading data using a
preRenderView event.
To reproduce this problem, create a test page:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
f:view contentType=text/html
h:body
h:form prependId=false enctype=multipart/form-data
f:metadata
f:event type=preRenderView
listener=#{playgroundController.load}/
/f:metadata
h:inputText value=#{playgroundController.car.colour}/
h:inputText value=#{playgroundController.car.make}/
h:outputText value=#{playgroundController.car}/
h:commandButton value=Talk
actionListener=#{playgroundController.talk}/
/h:form
/h:body
/f:view
/html
With a backing bean behind:
@Controller
@Scope( conversation.access )
public class PlaygroundController implements Serializable {
private Car car;
public PlaygroundController() {
System.out.println(\nNEW PLAY INSTANCE
+Integer.toHexString(hashCode())+\n);
}
public void load() {
System.out.println(\nLOAD +Integer.toHexString(hashCode())+\n);
car = new Car();
}
public void talk(ActionEvent evt) {
System.out.println(CAR: +car);
}
public Car getCar() {
return car;
}
public void setCar(Car car) {
this.car = car;
}
}
If the enctype is multipart/form-data, when I click on the submit button,
the bean will be instantiated again and the load method won't be called...
throwing an ugly exception. If the enctype is the default, everything works
as expected and the method talk(ActionEvent evt) will print the car in
the
console as expected.
I am using multipart/form-data because I wanted to upload some files. I can
see it is troublesome... anyone could explain me why?
Thanks!
Bruno
On 1 July 2010 17:09, Bruno Aranda brunoara...@gmail.com wrote:
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
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
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
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
