[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, 9 months
[JBoss JIRA] (JBSEAM-5001) Deadlock between SFSB EJB lock and Component.getInstanceFromFactory factoryLock calling factory from the same component
by Marek Schmidt (JIRA)
Marek Schmidt created JBSEAM-5001:
-------------------------------------
Summary: Deadlock between SFSB EJB lock and Component.getInstanceFromFactory factoryLock calling factory from the same component
Key: JBSEAM-5001
URL: https://issues.jboss.org/browse/JBSEAM-5001
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.3.0.BETA2
Environment: JBoss AS 7.1.2
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.CR1
The following sample demonstrates a deadlock between SFSB lock and the Component.getInstanceFromFactory factoryLock:
{code}
@Stateful
@Scope(ScopeType.SESSION)
@Name("test")
public class TestAction implements Test
{
public String test() {
Thread.sleep(500);
Component.getInstance("testString", true);
return "test";
}
@Factory(value="testString", scope=ScopeType.SESSION)
public String getTestString() {
return "testString";
}
@Remove
public void remove() {}
}
{code}
when test.xhtml contains:
{code}
<h:outputText value="#{test.test()} " />
{code}
and othertest.xhtml contains:
{code}
<h:outputText value="#{testString} " />
{code}
If the othertest.seam is requested just after (<500ms after) the test.seam with the same session cookie.
The problem seems to be that the #{test.test()} first locks the TestAction SFSB lock and then the Seam factory lock in the Component.getInstance call, while #{testString} locks the factoryLock first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBSEAM-5020) Binding component does not restore conversation
by Tiago Peruzzo (JIRA)
Tiago Peruzzo created JBSEAM-5020:
-------------------------------------
Summary: Binding component does not restore conversation
Key: JBSEAM-5020
URL: https://issues.jboss.org/browse/JBSEAM-5020
Project: Seam 2
Issue Type: Bug
Affects Versions: 2.3.0.BETA2
Environment: 2.3.0.BETA2 or 2.3.0.CR1-SNAPSHOT
Reporter: Tiago Peruzzo
Here is a simple scenario that demonstrates that when a binding is done in some component of view the conversation is no longer restored, if removed binding that conversation is restored with success.
{code:xml}
<h:form>
<h:outputText value="ConversationId: #{conversation.id}"/>
<br/>
<h:inputText value="#{myComponent.value}" binding="#{myBackingBean.input}"/>
<br/>
<h:commandButton action="test" value="Submit" />
</h:form>
{code}
{code:title=MyComponent.java}
@Scope(ScopeType.CONVERSATION)
@Name("myComponent")
public class MyComponent implements Serializable {
private static final long serialVersionUID = 1L;
public String value;
@Create
@Begin()
public void begin(){
}
public String getValue() {
return value;
}
public void setValue(String value) {
this.value = value;
}
}
{code}
{code:title=MyBackingBean.java}
@Scope(ScopeType.EVENT)
@Name("myBackingBean")
public class MyBackingBean implements Serializable {
private UIInput input;
public UIInput getInput() {
return input;
}
public void setInput(UIInput input) {
this.input = input;
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 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, 9 months
[JBoss JIRA] (JBSEAM-4939) pages.xml does not support "virtual" view-id without file on disk
by Andrea Martino (JIRA)
Andrea Martino created JBSEAM-4939:
--------------------------------------
Summary: pages.xml does not support "virtual" view-id without file on disk
Key: JBSEAM-4939
URL: https://issues.jboss.org/browse/JBSEAM-4939
Project: Seam 2
Issue Type: Bug
Components: Core, Framework
Affects Versions: 2.3.0.BETA1
Environment: JBOSS 7.1 AS + JSF2.1 + Richfaces 4.2.0.Final
Reporter: Andrea Martino
In Seam 2.2.x, it is possible to define a "virtual" view in pages.xml without any related file on disk.
For example, in Seam 2.2.x it is possible to define a redirect as following without having any "home.xhtml" file on disk:
<page view-id="/home.xhtml">
<navigation>
<redirect view-id="/welcome.xhtml"/>
</navigation>
</page>
In Seam 2.2.x, when entering "/myapp/home.seam" the browser is correctly redirected to "/myapp/welcome.seam". In Seam 2.3.0.Beta1 in JBOSS 7.1 AS, a FacesFileNotFoundException is thrown. This issue is similar to JBSEAM-4926.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[JBoss JIRA] (JBSEAM-4856) AS7 Multi-war ear Seam 2.2.2.Final fails deployment (race condition?)
by Todd Sproule (Created) (JIRA)
AS7 Multi-war ear Seam 2.2.2.Final fails deployment (race condition?)
---------------------------------------------------------------------
Key: JBSEAM-4856
URL: https://issues.jboss.org/browse/JBSEAM-4856
Project: Seam 2
Issue Type: Bug
Components: Core
Affects Versions: 2.2.2.Final
Environment: Ubuntu 11.10, Sun Java 1.6.0_26-b03, JBoss AS7 7.0.1.Final
Reporter: Todd Sproule
Deployment of a multi-war Seam ear into AS7 causes a deployment exception with duplicate component exception. This is easy to reproduce with any AS7 Seam ear and two wars.
16:19:13,605 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/seam-hello1]] (MSC service thread 1-3) Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener: java.lang.IllegalStateException: duplicate factory for: org.jboss.seam.web.webSession (duplicate is specified in components.xml)
at org.jboss.seam.core.Init.checkDuplicateFactoryExpressions(Init.java:227) [jboss-seam-2.2.2.Final.jar:]
at org.jboss.seam.core.Init.checkDuplicateFactory(Init.java:220) [jboss-seam-2.2.2.Final.jar:]
at org.jboss.seam.core.Init.addFactoryValueExpression(Init.java:283) [jboss-seam-2.2.2.Final.jar:]
at org.jboss.seam.init.Initialization.installComponents(Initialization.java:1152) [jboss-seam-2.2.2.Final.jar:]
at org.jboss.seam.init.Initialization.init(Initialization.java:737) [jboss-seam-2.2.2.Final.jar:]
at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:36) [jboss-seam-2.2.2.Final.jar:]
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3368) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3821) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months