[JBoss Portal] - WSRP and managed transactions
by fpa1974
This is for version 2.6.2 of the portal.
I have a question regarding managed transactions. We have developed a portlet that is using hibernate and it is managing its own transactions. If this is deployed and viewed locally on a JBoss portal instance everything works ok.
Now the problem. When this portlet is deployed on a JBoss portal and exposed through WSRP to another JBoss portal instance there is an error message that comes out mentioning and you cannot call commit in a managed transaction. Something tells me that the WSRP request is processed within a managed transaction and that propagates to the portlet. Is it possible to disable that so portlets that manage their own transactions run properly?
This is the SQLException:
java.sql.SQLException: You cannot commit during a managed transaction!
If necessary I can put the whole stack trace in here.
Thanks,
Florian
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101998#4101998
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101998
18 years, 5 months
[JBoss Seam] - Re: Can't intercept FileUploadException in 1.2.1 with update
by JakeC
Sorry. Of course, 4.0.5 is the JBOSS version. I mean Seam 1.2.1.
OK, I think I see why the ExceptionFilter doesn't catch this. MultipartFilter is annotated with @Intercept(NEVER).
I'm sure this is there for a very good reason. If I remove it, I get the following exception:
14:13:33,015 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
| java.lang.IllegalAccessException: Class org.jboss.seam.util.Reflections can not access a member of class org.jboss.seam.web.AbstractFilter with modifi
| ers ""
| at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
| at java.lang.reflect.Method.invoke(Method.java:588)
| at org.jboss.seam.util.Reflections.invoke(Reflections.java:20)
| at org.jboss.seam.intercept.RootInvocationContext.proceed(RootInvocationContext.java:31)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
| at org.jboss.seam.interceptors.RollbackInterceptor.aroundInvoke(RollbackInterceptor.java:34)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:113)
| at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:151)
| at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:87)
| at org.jboss.seam.web.MultipartFilter_$$_javassist_13.matchesRequestPath(MultipartFilter_$$_javassist_13.java)
| at org.jboss.seam.web.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:47)
| at org.jboss.seam.web.SeamFilter.doFilter(SeamFilter.java:84)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.ajax4jsf.framework.ajax.xmlfilter.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:96)
| at org.ajax4jsf.framework.ajax.xmlfilter.BaseFilter.doFilter(BaseFilter.java:220)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| at java.lang.Thread.run(Thread.java:619)
Is it possible to get exception handling to work with MultipartRequest?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101993#4101993
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101993
18 years, 5 months
[JBoss Seam] - Re: pages.xml action method fired on ajax requests - must be
by gothmog
I'm not too keen either, however the only scenario that I'm struggling to solve elegantly is the scenario where you have a page that can be navigated to in a number of ways and before you display that page you need the model to be setup correctly, i.e. you need to query something or change state in say a conversation before the page is rendered. And you can't rely on starting a conversation as you are already in one.
Now <page view-id="..." action="#{setupmethod}"> looks like a good candidate to centralise this behaviour, i.e. it doesn't matter how you get to this page you know the model is going to be 'prepared' for it in a pull manner.
However you only want this to happen in two cases, the first time you land on the page and when the user refreshes the page (which is arguably re-landing on the same page). You don't want this code to run when you are interacting with the page. Now the traditional GET and POST solve this problem as you know where you are, but with restful urls this becomes difficult.
The only other way (I can think of) is to track all navigation requests to the page and call some setup code in a push manner (not as elegant and maintenance proof) and then redirect to the page and not use <page view-id="" action="#{setupMethod}"> at all.
It was my understanding from reading the docu that the action method on the element was designed for implementing some sort of MVP pattern?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4101986#4101986
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4101986
18 years, 5 months