[JBoss JIRA] Created: (AS7-1737) Domain usability: add check for the same name of the host
by Radoslav Husar (JIRA)
Domain usability: add check for the same name of the host
---------------------------------------------------------
Key: AS7-1737
URL: https://issues.jboss.org/browse/AS7-1737
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 7.0.1.Final, 7.0.0.Final
Reporter: Radoslav Husar
Assignee: Brian Stansberry
If you join in a remote host with the same name as the master (e.g. "master") it's really hard to see what went wrong. Everything boots OK but its impossible to manage. The console completely breaks (see screenshot) on the other controller.
The controller should check if it can connect with that name.
Adding error log if anyone is searching for the issue:
{code}
[Host Controller] 14:39:02,093 ERROR [org.jboss.as.controller] (pool-4-thread-3) Operation ("read-attribute") failed - address: ([
[Host Controller] ("host" => "master"),
[Host Controller] ("server-config" => "undefined")
[Host Controller] ]): java.util.NoSuchElementException: "server-config" => "undefined"
[Host Controller] at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.host.controller.operations.ServerStatusHandler.execute(ServerStatusHandler.java:62) [jboss-as-host-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ReadAttributeHandler.doExecute(GlobalOperationHandlers.java:378) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:828) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.execute(OperationSlaveStepHandler.java:77) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:85) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:119) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.remote.TransactionalModelControllerOperationHandler$ExecuteRequestHandler$1.run(TransactionalModelControllerOperationHandler.java:111) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
[Host Controller] at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
[Host Controller]
[Host Controller] 14:39:02,104 ERROR [org.jboss.as.controller] (pool-4-thread-4) Operation ("read-attribute") failed - address: ([
[Host Controller] ("host" => "master"),
[Host Controller] ("server-config" => "undefined")
[Host Controller] ]): java.util.NoSuchElementException: "server-config" => "undefined"
[Host Controller] at org.jboss.as.controller.registry.BasicResource.requireChild(BasicResource.java:95)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.readModel(OperationContextImpl.java:697)
[Host Controller] at org.jboss.as.host.controller.operations.ServerStatusHandler.execute(ServerStatusHandler.java:62)
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ReadAttributeHandler.doExecute(GlobalOperationHandlers.java:378)
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:828)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.execute(OperationSlaveStepHandler.java:77)
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:85)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298)
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223)
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:119)
[Host Controller] at org.jboss.as.controller.remote.TransactionalModelControllerOperationHandler$ExecuteRequestHandler$1.run(TransactionalModelControllerOperationHandler.java:111)
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
[Host Controller] at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
[Host Controller]
[Host Controller] 14:39:03,924 ERROR [org.jboss.as.controller] (pool-4-thread-3) Operation ("read-children-names") failed - address: ([("host" => "master")]): java.lang.IllegalArgumentException
[Host Controller] at org.jboss.dmr.ModelValue.getChild(ModelValue.java:108) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final]
[Host Controller] at org.jboss.dmr.ModelNode.get(ModelNode.java:689) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.createOverallResult(ServerOperationsResolverHandler.java:130) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:103) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ReadChildrenNamesOperationHandler.execute(GlobalOperationHandlers.java:431) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.execute(OperationSlaveStepHandler.java:77) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:85) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:119) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.remote.TransactionalModelControllerOperationHandler$ExecuteRequestHandler$1.run(TransactionalModelControllerOperationHandler.java:111) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
[Host Controller] at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
[Host Controller]
[Host Controller] 14:39:04,368 ERROR [org.jboss.as.controller] (pool-4-thread-3) Operation ("read-children-names") failed - address: ([("host" => "master")]): java.lang.IllegalArgumentException
[Host Controller] at org.jboss.dmr.ModelValue.getChild(ModelValue.java:108) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final]
[Host Controller] at org.jboss.dmr.ModelNode.get(ModelNode.java:689) [jboss-dmr-1.0.0.Final.jar:1.0.0.Final]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.createOverallResult(ServerOperationsResolverHandler.java:130) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:103) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$ReadChildrenNamesOperationHandler.execute(GlobalOperationHandlers.java:431) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.OperationSlaveStepHandler.execute(OperationSlaveStepHandler.java:77) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:85) [jboss-as-domain-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.executeStep(OperationContextImpl.java:351) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.doCompleteStep(OperationContextImpl.java:298) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.OperationContextImpl.completeStep(OperationContextImpl.java:223) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:119) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at org.jboss.as.controller.remote.TransactionalModelControllerOperationHandler$ExecuteRequestHandler$1.run(TransactionalModelControllerOperationHandler.java:111) [jboss-as-controller-7.0.1.Final-redhat-1.jar:7.0.1.Final-redhat-1]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
[Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
[Host Controller] at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
[Host Controller]
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (AS7-1485) Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
by Jason Greene (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-1485?page=com.atlassian.jira.plugin.s... ]
Jason Greene commented on AS7-1485:
-----------------------------------
We had to patch that xerces problem, which is why you don't see it in AS7:
https://github.com/jboss/xerces/commit/8d7680fc7ffc82278efaa7ebad2ae1d05b...
Xerces appears to originally been split into smaller projects which used SPI discovery. They merged them altogether but kept the SPI discovery, so if TCCL ever contains another version of xerces parts of it get used with the other one. The patch above rips all of that nonsense out.
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> -------------------------------------------------------------------------
>
> Key: AS7-1485
> URL: https://issues.jboss.org/browse/AS7-1485
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.0.0.Final, 7.0.2.Final
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: Open To Community
>
>
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]. (main) Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
> java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
> at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.getConfiguredFactory(ConfigureListener.java:702)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:674)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:648)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:156)
> at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:4389)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:145)
> at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
> at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
--
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
12 years, 8 months
[JBoss JIRA] (AS7-1485) Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
by Brad Maxwell (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-1485?page=com.atlassian.jira.plugin.s... ]
Brad Maxwell commented on AS7-1485:
-----------------------------------
Yes, I think we have it worked out in EAP, I'll be back next week and will rebuild the JSF 1.2.15 for AS 7. We found an additional problem area in JSF 1.2.x, calling methods like newDocumentBuilder / newSAXParser the Xerces code was doing some weird stuff where it picked a classloader then loaded classes from it, this didn't work in JBoss 5.x, however it does seem to work in AS 7 (JSF2), I suspect because the JBoss Modules is giving a different classloader.
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> -------------------------------------------------------------------------
>
> Key: AS7-1485
> URL: https://issues.jboss.org/browse/AS7-1485
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.0.0.Final, 7.0.2.Final
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: Open To Community
>
>
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]. (main) Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
> java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
> at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.getConfiguredFactory(ConfigureListener.java:702)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:674)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:648)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:156)
> at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:4389)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:145)
> at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
> at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
--
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
12 years, 8 months
[JBoss JIRA] (AS7-1485) Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
by Jason Greene (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-1485?page=com.atlassian.jira.plugin.s... ]
Jason Greene commented on AS7-1485:
-----------------------------------
I'm not sure where the source for that release came from but I assume it was this:
https://github.com/jboss/mojarra/commit/7c3c8a62c0af019c61e61615f82ba10fe... ?
The problem seems to be that the patch is too broad, the TCCL swapping should be wrapped around just JAXP factory instance creation and no wider.
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> -------------------------------------------------------------------------
>
> Key: AS7-1485
> URL: https://issues.jboss.org/browse/AS7-1485
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.0.0.Final, 7.0.2.Final
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: Open To Community
>
>
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]. (main) Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
> java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
> at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.getConfiguredFactory(ConfigureListener.java:702)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:674)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:648)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:156)
> at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:4389)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:145)
> at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
> at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
--
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
12 years, 8 months
[JBoss JIRA] (AS7-1485) Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
by Jason Greene (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-1485?page=com.atlassian.jira.plugin.s... ]
Jason Greene commented on AS7-1485:
-----------------------------------
Brad do you want to fix this one?
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> -------------------------------------------------------------------------
>
> Key: AS7-1485
> URL: https://issues.jboss.org/browse/AS7-1485
> Project: Application Server 7
> Issue Type: Bug
> Components: JSF
> Affects Versions: 7.0.0.Final, 7.0.2.Final
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: Open To Community
>
>
> Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory
> ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]. (main) Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener
> java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory
> at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.getConfiguredFactory(ConfigureListener.java:702)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:674)
> at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:648)
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:156)
> at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60)
> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910)
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:4389)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321)
> at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:145)
> at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
> at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
--
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
12 years, 8 months
[JBoss JIRA] (AS7-2078) Support absolute paths in RelativePathService
by Brian Stansberry (Created) (JIRA)
Support absolute paths in RelativePathService
---------------------------------------------
Key: AS7-2078
URL: https://issues.jboss.org/browse/AS7-2078
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 7.1.0.Beta1
There are situations where it is difficult for a user to specify that a "path" attribute's value is absolute when used in conjunction with a "relative-to" attribute; specifically when the relative-to attribute has a default value (e.g. jboss.server.data.dir). In these situations, the xsd should state that "path" will only be treated as relative if it is not an absolute path (i.e. starts with '/', '\\' or 'x:\' where 'x' is any character in the range [a-z] or [A-Z]). In these situations, RelativePathService should check if the 'path' value is absolute, and if it is, delegate to AbsolutePathService, ignoring any 'relative-to' value.
In cases where 'relative-to' has no default, the existing behavior should be preserved; the presence or absence of 'relative-to' controls whether 'path' is treated as absolute, and including an absolute path in cojunction with a 'relative-to' value is a user error.
--
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
12 years, 8 months
[JBoss JIRA] (JBREM-1303) Channel's CloseHandler is not invoked on the server side if the client side channel disconnects
by jaikiran pai (Created) (JIRA)
Channel's CloseHandler is not invoked on the server side if the client side channel disconnects
-----------------------------------------------------------------------------------------------
Key: JBREM-1303
URL: https://issues.jboss.org/browse/JBREM-1303
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: jaikiran pai
If a client side Channel disconnects (ex: the client program terminates) the server side Channel's CloseHandler(s) are not invoked. As a result, if the server side Channel is later used for writing out messages it runs into a Channel closed exception:
{code}
org.jboss.remoting3.NotOpenException: JBREM00206: Channel is not open
at org.jboss.remoting3.remote.RemoteLogger_$logger.channelNotOpen(RemoteLogger_$logger.java:97) [jboss-remoting-3.2.0.Beta2.jar:3.2.0.Beta2]
at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:86) [jboss-remoting-3.2.0.Beta2.jar:3.2.0.Beta2]
at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.sendModuleAvailability(VersionOneProtocolChannelReceiver.java:183) [jboss-as-ejb3-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.deploymentAvailable(VersionOneProtocolChannelReceiver.java:161) [jboss-as-ejb3-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.ejb3.deployment.DeploymentRepository.add(DeploymentRepository.java:57) [jboss-as-ejb3-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.as.ejb3.deployment.ModuleDeployment.start(ModuleDeployment.java:49) [jboss-as-ejb3-7.1.0.Alpha2-SNAPSHOT.jar:7.1.0.Alpha2-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
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]
{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
12 years, 8 months
[JBoss JIRA] (JBRULES-3245) Cannot use Mockito to Mock Events; result is ClassCastException
by Rob Crawford (Created) (JIRA)
Cannot use Mockito to Mock Events; result is ClassCastException
---------------------------------------------------------------
Key: JBRULES-3245
URL: https://issues.jboss.org/browse/JBRULES-3245
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (fusion)
Affects Versions: 5.3.0.CR1
Environment: Java 1.6, Windows
Reporter: Rob Crawford
Assignee: Mark Proctor
Attachments: mocktest.zip
AbstractRuleBase.getTypeDeclaration(Class clazz) cannot determine what type is being mocked, so attempting to mock an event causes the system to fall back to the object being a simple fact. Have test classes to attach to issue: explanation of what I'm seeing:
testMockObjectAsEvent: may not be the same issue, but the system cannot identify the correct extractor for the event timestamp, and attempts to get a Long value from a method that returns a Date. In this case, it's at least identified as an event.
testMockObjectAsEventTwoLevels: mock is of an interface that extends a declared event; in this case the mock is never identified as an event, but still follows the path into the rule's window function, resulting in an attempt to cast the mock's DefaultFactHandle to an EventFactHandle.
--
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
12 years, 8 months