[JBoss Seam] - Question on Seam Request/Response Cycle
by ajaneesh
Hi,
Is there some documentation that explains the request cycle in a typical seam application. i.e starting form a xyz.seam, how the request maps to entries in navigation.xml, pages.xml etc.
Basically trying to understand what is the first thing that happens inside of seam when a xyz.seam request comes in.
In the booking example, the non *.seam request "localhost:8080/jboss-seam-booking'" is getting redirected to home.xhtml. How is this happening or where is this configured. At first it looked like the refresh configured in the index.html was doing this but on further investigation, found that index.html was no where in the picture as welcome files list was not configured. Also found that home.seam is not a default as the registration application redirects to register.seam by default.
Any explanations or pointers in this regard will be greatly appreciated.
Thanks
Ajaneesh
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034141#4034141
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034141
19 years
[JCA/JBoss] - Re: Are exception-sorter expected to work for xa-datasource?
by nathanmeyers
"weston.price(a)jboss.com" wrote : anonymous wrote :
| | The situation leading to this error was restart of the db server, so I have a pool full of dead connections.
| |
|
| Your *-ds.xml file does not include a valid connection checker element which means that potentially invalid connections can remain in the pool for use. Take a look at
|
| http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossJCAPooling
|
| On how to configure this.
|
I'm familiar with <check-valid-connection-sql>. The point of this exception-sorter exercise is to get away from the high expense of that approach. Ideally, we want to accept the cost of a single failure - followed by immediate invalidation of the pool - rather than the overhead of very frequent connection checks.
The distinction between XA errors and connection errors is an artifact of how the XA transactions are managed. The bottom line is that a pool full of connections has been rendered bad by a db restart - it's a connection issue any way you cut it, and I'd like to flush the pool the instant that problem is detected.
For reasons you've now explained, I know I can't currently do that in certain parts of the XA lifecycle. And for mysterious reasons (the second scenario), I can't even do that when I should be able to.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034138#4034138
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034138
19 years