Well, SEMPPL seems work fine to me in JBoss 4.0.4GA + Seam 20060520 +
jsf-facelets 1.1.4.
It has still a drawback, anyway: when an exception occurs in a page, it leaks
the serving transaction which is left active in the thread and may eventually
be propagated to other servlets.
For the very
pbrewer_uk wrote : I do sometimes experience an exception that brings down
the whole servlet
I think this is not the same problem I'm experiencing: I get errors caused by
transactions already active after the first exception.
Please note that the first exception is due to a software mistake
This is an interesting new feature.
Do you think there would be any usefulness in enhancing it (or perhaps
extending it) to the case in which one is popping and redirecting from the
topmost conversation?
I guess it could be usefull in many cases. In example, a logon issued by a
login
Great! Gonna try it!
Thanks,
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3943242#3943242
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3943242
---
Using Tomcat but
I found a (very) temporary workaround to the transaction-still-there: don't use
the SeamExtendedManagedPersistencePhaseListener.
I had somewhere a servlet filter adding transactional behaviour to http
requests. It basicly wraps a transaction begin/commit around an http request,
rolling the
anonymous wrote : If you try to mix your own tx management with Seam tx
management, you will break stuff. No wonder you have been having problems.
Somehow, I'd the feeling you would reply this way... :)
Gavin, I added the transactional filter to the request chain to use the
SeamServletFilter,
anonymous wrote : As I read his thread, he did stop using SEMPPL and switched
to the regular SeamPhaseListener + custom TX management because he could not
resolve the exception. He was never simultaneously using SEMPPL + custom TX
management.
Right.
View the original post :
What about the following? After restarting jboss and the app and accessing this
page from the main one, the page is correctly shown but the request ends with a
RollbackException, which mean someone marked rollback-only the transaction.
Please note that no place in the involved application code
I'm having a bad time with it. I'm developing a webapp in which I have
conversations (and plan to use jBPM) and some custom servlet for handling
images.
The problem is that, sometime, my image servlet throws an exception by which
I'm told that a UserTransaction is already active.
The image
You're right: cold-deploying the app I don't get anymore an IllegalWhatever
exception due to an already-started transaction from the non-seam servlet.
But now I get the following when accessing a parametrized page (eg.:
thepage.jsf?c=3) from the very same page but different parameter (eg: from
Oh, by the way: I'm now using JBoss-4.0.4-CR2 and jboss-seam-CVS20060423.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3939072#3939072
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3939072
Well, it may be. But why it happens on finalizing a component and not when
injecting EMs?
Also, if it is a classpath problem, I would expect to see it everytime, not in
few, exact conditions.
Isn't that there is a classloader problem somewhere? Like, say, the tomcat's
thread pool is grown
Almost: splitting the MyClass in two classes, one outjecting idCat and one
outjecting currentCategory, as well as emulating the behaviour of @Factory
through @Out(s) on getters solved the problem.
It is not that elegant, but works.
After changes I thought that retrieving idCat in
Dears,
I have something like this in a Seam component of mines:
| @Name(myComp)
| @Scope(ScopeType.EVENT)
| @Intercept(InterceptionType.ALWAYS)
| public class MyComp {
| @In(create = true)
| private HibernateEntityManager theDatabase;
|
|
| @RequestParameter
|
It is not that easy to post: it is based on a two-level template and two custom
tags in a ui:repeat/c:forEach...
What are you looking for? I'll post the needed fragment.
This is the base page, however:
| ?xml version=1.0 encoding=UTF-8?
| !DOCTYPE composition PUBLIC -//W3C//DTD XHTML 1.0
Well, context demarcation happens in component code, not in jsf page...
However, actually I don't use it at all. I will for some pages, but not yet.
@Out with @Factory always works to me when the outjected value is asked by jsf
pages. It never works to me when it is used from inside the same
Ok, my brain was elsewhere while writing my previous post... Now I got your
point.
I think there shouldn't be any difference in grabbing an attr at context or
from component level: after all, in any case there is an underlying faces
context triggering the (in my case cascaded) bijections...
Of course, it is:
| @RequestParameter
| private String c;
|
Something went wrong in my previous cut'n'paste. The code I'm using is correct,
however...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3936015#3936015
Reply to the post :
[EMAIL PROTECTED] wrote : Yes, it does seem to fix the bug in all cases. You
have to return an outcome and trigger a navigation rule from faces-config.xml.
I have this problem, too. But I don't (yet) have any interceptor triggered: I'm
actually prototipizing a site and have only navigation
[EMAIL PROTECTED] wrote : Guys this is NOTHING TO DO WITH SEAM
Well, I didn't mind to call for an impeachment of Seam in this. Just, since the
people using Seam is also using myfaces+facelets, chances are they are up to
date with news about this issue...
Did I do something wrong?
View the
However, you were right, Gavin: upgrading the MyFaces core library (api+impl)
to the 1.1.3-SNAPSHOT dated march 27, 2006, solved this issue at least for me.
To whom it may concern, the MyFaces core's 1.1.3 nightly snapshots may be
downloaded from http://cvs.apache.org/builds/myfaces/nightly/.
21 matches
Mail list logo
