[JBoss JIRA] Created: (JBSEAM-4693) 6.12.2. Enabling Seam exception handling : web:exception-filter in components.xml
by simon lebettre (JIRA)
6.12.2. Enabling Seam exception handling : web:exception-filter in components.xml
---------------------------------------------------------------------------------
Key: JBSEAM-4693
URL: https://jira.jboss.org/browse/JBSEAM-4693
Project: Seam
Issue Type: Task
Components: Documentation Issues
Reporter: simon lebettre
this does not make sense :
"
6.12.2. Enabling Seam exception handling
To enable Seam's exception handling, we need to make sure we have the master servlet filter declared in web.xml:
"
==> Of course the master filter is in web.xml !
this would be more relevant :
"we need to make sure that <web:exception-filter url-pattern="*.seam" /> is declared in components.xml"
I m not being picky about the doc, it's been 7 months I have a bad user experience or loose some exception feedback because I forgot this line in components.xml !
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4487) Concurrent requests; one invalidates the session, results in recursive loop of session creation
by dave atkins (JIRA)
Concurrent requests; one invalidates the session, results in recursive loop of session creation
-----------------------------------------------------------------------------------------------
Key: JBSEAM-4487
URL: https://jira.jboss.org/jira/browse/JBSEAM-4487
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.2.0.GA, 2.2.0.CR1, 2.1.2.GA, 2.1.2.CR2, 2.1.2.CR1, 2.1.1.GA
Environment: Jboss 4.2.2 with shipped Tomcat on Linux.
Reporter: dave atkins
I noticed that we had an massive number of sessions on one of our tomcat nodes that hosts our modest Seam app. After some investigation I discovered this in the log
2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session
This is repeated for thousands of lines. After digging around the seam code I realised that if you have two concurrent requests and one invalidates the session before the other is finished, seam goes into an recursive loop of session creation (normally ended by stack overflow). Here's a stack trace showing two recursions.
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
This problem is partially documented here - https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix didn't solve the root cause of the problem.
The problem is caused by the SessionMap used by ServerConversationContext. Internally the session map uses HttpServletRequest.getSession(true) to retrieve the session, which creates a new session if the one defined on the HttpServletRequest is invalid or null. Unfortunately, when the new session is created session listeners are informed before the session has been set on the HttpServletRequest. Seam is one of these session listeners and creates a new Identity on session creation, which in turn accesses the SessionMap, still before the new Session has been set on the request. This leads to an infinite recursive loop.
The SessionMap used is returned by externalContext.getSessionMap(). One solution could be to implement our own SessionMap that doesn't attempt to create a new session if the current session is invalid or null, although I've no idea how this would impact on other Seam code.
The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application in another tab before the search has completed the problem arises.
We are using seam 2.1.1.GA. I've looked at the source code for the latest release and it appears that the problem will still occur due to use of SessionMap.
Out current workaround is to add a ThreadLocal to Identity.create that counts recursive calls. If more then two recursive calls are detected an IllegalProcessState exception is thrown. This isn't definitely isn't a permanent solution, but stops our server creating 100,000 sessions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] Created: (JBSEAM-4807) Seamdiscs example fails to deploy to JBoss AS 6
by Martin Gencur (JIRA)
Seamdiscs example fails to deploy to JBoss AS 6
-----------------------------------------------
Key: JBSEAM-4807
URL: https://issues.jboss.org/browse/JBSEAM-4807
Project: Seam 2
Issue Type: Bug
Components: Examples
Affects Versions: 2.2.2.Final
Reporter: Martin Gencur
Assignee: Marek Novotny
Fix For: The future
JBoss AS 6 cannot parse tag library file from trinidad-impl.jar and deployment fails. This error does *NOT* arise on JBossAS 5.
Stack Trace:
15:49:25,252 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Parse: name=vfs:///home/mgencur/Java/jboss6/jboss6final/jboss-6.0.0.Final/server/default/deploy/jboss-seam-discs.ear state=PreParse mode=Manual requiredState=Parse: org.jboss.deployers.spi.DeploymentException: Error creating managed object for vfs:///home/mgencur/Java/jboss6/jboss6final/jboss-6.0.0.Final/server/default/deploy/jboss-seam-discs.ear/jboss-seam-discs.war/
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:383) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:343) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:315) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.deploy(AbstractParsingDeployerWithOutput.java:255) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1603) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.GA]
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.GA]
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.GA]
at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.Final]
at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:143) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.2.2]
at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:57) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.2.2]
at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:95) [:0.2.2]
at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.2.2]
at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.2.2]
at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.2.2]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_21]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_21]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_21]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_21]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0_21]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
Caused by: org.jboss.xb.binding.JBossXBException: Failed to parse source: vfs:///home/mgencur/Java/jboss6/jboss6final/jboss-6.0.0.Final/server/default/deploy/jboss-seam-discs.ear/jboss-seam-discs.war/WEB-INF/lib/trinidad-impl.jar/META-INF/tr.tld@1,238
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:224) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:178) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:257) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.util.JBossXBHelper.parse(JBossXBHelper.java:231) [jbossxb.jar:2.0.3.GA]
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:137) [:2.2.0.GA]
at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:64) [:6.0.0.Final]
at org.jboss.deployment.TldParsingDeployer.parse(TldParsingDeployer.java:38) [:6.0.0.Final]
at org.jboss.deployers.vfs.spi.deployer.SchemaResolverDeployer.parse(SchemaResolverDeployer.java:121) [:2.2.0.GA]
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.handleMultipleFiles(AbstractVFSParsingDeployer.java:446) [:2.2.0.GA]
at org.jboss.deployers.vfs.spi.deployer.AbstractVFSParsingDeployer.parse(AbstractVFSParsingDeployer.java:319) [:2.2.0.GA]
at org.jboss.deployers.spi.deployer.helpers.AbstractParsingDeployerWithOutput.createMetaData(AbstractParsingDeployerWithOutput.java:376) [:2.2.0.GA]
... 42 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: Failed to parse schema for nsURI=http://java.sun.com/xml/ns/javaee, localName=taglib, schemaLocation=null
at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:350) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.sunday.unmarshalling.SundayContentHandler.startElement(SundayContentHandler.java:176) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.startElement(SaxJBossXBParser.java:401) [jbossxb.jar:2.0.3.GA]
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.xinclude.XIncludeHandler.startElement(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:209) [jbossxb.jar:2.0.3.GA]
... 52 more
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 31:3 The declaration for the entity "HTML.Version" must end with '>'.
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40) [jbossxb.jar:2.0.3.GA]
at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source) [xercesImpl.jar:6.0.0.Final]
at org.jboss.xb.binding.Util.loadSchema(Util.java:394) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:178) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:149) [jbossxb.jar:2.0.3.GA]
at org.jboss.xb.binding.resolver.AbstractMutableSchemaResolver.resolve(AbstractMutableSchemaResolver.java:342) [jbossxb.jar:2.0.3.GA]
... 67 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4391) Need to add transaction propagation types to @Transactional
by asookazian (JIRA)
Need to add transaction propagation types to @Transactional
-----------------------------------------------------------
Key: JBSEAM-4391
URL: https://jira.jboss.org/jira/browse/JBSEAM-4391
Project: Seam
Issue Type: Feature Request
Components: Core
Affects Versions: 2.2.0.GA
Environment: N/A
Reporter: asookazian
The current tx propagation types for use with @Transactional are the following:
REQUIRED, MANDATORY, SUPPORTS, NEVER;
Here is a comment from the TransactionalPropagationType enum class:
* Transaction propagation strategies for Seam JavaBean components. Note that unlike EJB3 components, there are no strategies for suspending transactions.
Please add REQUIRES_NEW and NOT_SUPPORTED. I am unable to solve my functional requirement of calling a webservice which inserts into remote db (which does not require a tx) and inserting into multiple local db tables (requires tx) using JavaBean components and Seam @Transactional. The requirement is that even if the webservice call fails, the local db inserts should continue and succeed (i.e. no atomicity, no rollback).
There is an action method in my JavaBean Seam component that is invoked from a commandButton in JSF page. Then there are two private methods that are invoked from that public method. One requires tx support, the other does not. With EJB3, I would simply use NOT_SUPPORTED for one and REQUIRES_NEW for the other. Now using JavaBeans and @Transactional, I cannot solve my problem in terms of tx support requirements. @Transactional only works on public methods.
I tried recalling the component's private method (now refactored to public with @Transactional) using Component.getInstance("foo"); but that did not work.
Spring has robust tx support like EJB 3. Seam needs to be ramped up in terms of tx support for JavaBean components.
References:
http://www.seamframework.org/Community/TransactionalPropagationTypes
http://www.seamframework.org/Community/TransactionalOnPrivateMethod
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] Created: (JBSEAM-4512) BPM task does not rollback
by Jason E (JIRA)
BPM task does not rollback
--------------------------
Key: JBSEAM-4512
URL: https://jira.jboss.org/jira/browse/JBSEAM-4512
Project: Seam
Issue Type: Bug
Components: BPM
Affects Versions: 2.2.0.GA
Environment: Testing this on Windows XP. Deploying to JBoss AS 4.2.2
Reporter: Jason E
I have made a simple change to the ShipAction.java class in the dvdstore example that ships with Seam. Here is the change
//@EndTask
public String ship() {
order.ship(track);
TaskInstance ti = ManagedJbpmContext.instance().getTaskInstance(taskInstance.getId());
taskInstance.end();
if(true) throw new RuntimeException("TESTING");
return "admin";
}
I commented out the end task annotation and I am ending the task via the TaskInstance API. When I throw the Runtime exception the changes to the ORDERS entity bean (i.e. updating the tracking number) rolls back. The problem is that the task instance change (i.e. ending the task) does not rollback. It appears that jBPM is flushing its changes in another db transaction. This seems like a bug since I would expect the ending of my task to also rollback. This seems like the desired behavior.
This was the only change I made to the dvdstore example that ships with Seam 2.2.0.GA so it should be easy to reproduce.
Thanks!
Jason
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] Created: (SEAMSECURITY-86) Scheme setting for pages in @ViewConfig
by Bill Elliot (JIRA)
Scheme setting for pages in @ViewConfig
---------------------------------------
Key: SEAMSECURITY-86
URL: https://issues.jboss.org/browse/SEAMSECURITY-86
Project: Seam Security
Issue Type: Feature Request
Affects Versions: 3.0.0.Final
Reporter: Bill Elliot
Is there a way in Seam 3 to do like in the Page definitions of Seam 2 to specify the Scheme (HTTP/HTTPS) to use for a specific page? I need to be able to place the login and password changing screens into HTTPS for increased security and best practices. This could likely be done in the Pages definition under a @ViewConfig. Possibly adding a new annotation @Scheme("HTTPS").
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months