"g.tomassoni" wrote : 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.
This should not be possible if you have SeamExceptionFilter.
By the way, it shou
"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 a
Cheers Gavin, I shall add that to my list of breakpoints to investigate when
things go strange!
g.tomassoni wroteanonymous wrote : Do you experience the same?
I do sometimes experience an exception that brings down the whole servlet -
requiring a tomcat reboot. So far these (infrequent) exceptio
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
Unfortunately, I've just upgraded to CR3 (embedded-ejb with tomcat) and
reinstated my original error and the stack traces are still hiding the point of
failure.
Perhaps an @Out(scope=ScopeType.CONVERSATION) and a @DataModel annotation on
the same field is just too much of a strange thing to do.
Put a breakpoint in Component.inject() or Component.outject() and find out what
the actual underlying exception is.
C'mon guys, the debugger is your friend!
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3946354#3946354
Reply to the post :
http://www.jboss.c
It's fixed (for me at least) in JBoss 4.0.4GA / Seam 1.0.0CR3 (which is a huge
relief!)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3946132#3946132
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3946132
This, to me, is a bit of a show-stopper. I've just spent the 4 hours trying to
track down the cause of a RollbackException and eventually discovered that it
was due to annotating a variable with @Out and @DataModel.
Is there any progress/updates/fixes on the hiding of actual exceptions?
What is
It wasn't clear to me that the "synchronization exception" is responsible for
swallowing up other exception causes. In a post in this same thread it was
said that "either the application or JSF is swallowing exceptions", which
doesn't appear to be the case at all.
Is this exception masking con
anonymous wrote : So is it possible that the actual reason for the rollback is
being swallowed up by EJB3 trying to register synchronizations?
Exactly. I thought I had already made that bit clear in this or another thread.
anonymous wrote : From what I can (finally) tell, I have a Session scoped
anonymous wrote :
| ... so there is no way that setRollbackOnly() is ever called w/o an
exception propagation. So unless either the application or JSF is swallowing
exceptions, there _is_ an exception.
|
If the transaction times out, it will be marked for rollback by another thread
and in
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 :
http://www.jboss.c
anonymous wrote : Right, but SEMPPL does tx management. In fact, that is *all*
it does. If you want to do your own tx management, you don't need it.
As I read his thread, he did stop using SEMPPL and switched to the regular
SeamPhaseListener + custom TX management because he could not resolve t
Yes I mean SeamExceptionFilter, my bad.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3940199#3940199
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3940199
---
Using
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, n
Right, but SEMPPL does tx management. In fact, that is *all* it does. If you
want to do your own tx management, you don't need it.
anonymous wrote : I wish whatever code was marking the transaction as
rolledback would throw an exception as it's rolling it back
The only things that call setRollb
He's not using SEMPPL + his own TX management. He's using his own TX
management despite SEMPPL.
He only moved away from SEMPPL to his own TX management when he could not
resolve the exception previously mentioned in this thread: "could not register
synchronization with JTA TransactionManager",
anonymous wrote : 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 transaction back on exceptions.
If you try to mix your own tx management with Seam tx management, you will
break st
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 tran
First step is to figure out why the txn is getting rolled back ;-)
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3940033#3940033
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3940033
-
g.tomassoni, did you ever find a solution to your problem of:
"could not register synchronization with JTA TransactionManager"
We are experiencing this after upgrading Seam/Jboss/EJB3 and are unable to find
the source. Similar to your description, the first request works fine, and
then the sec
Sure, Seam components will often mark the transaction rollbackonly when an
exception propagates out of them.
For JavaBean components, it happens whenever *any* exception is thrown. For EJB
session beans it happens according to the spec rules.
However, there is a bug in Hibernate here (that caus
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 d
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 from
How about fixing this to begin with:
Caused by: java.lang.ClassNotFoundException:
org/jnp/interfaces/NamingContextFactory
Looks like you have JNDI problems.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3939073#3939073
Reply to the post :
http://www.jbo
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=bb&op=viewtopic&p=3939072#3939072
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3939072
---
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
There was a bug like what you described, and one day I spent hours trying to
track it down and concluded that it was not a bug in Seam, but rather a problem
that only occurred after hot redeployment. I have always managed to make it go
away by restarting JBoss.
However, I have not seen it recen
28 matches
Mail list logo
