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
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
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
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]
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
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
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
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
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
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.
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
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
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
13 matches
Mail list logo
