[JBoss JIRA] (TEIID-2650) A jboss server in domain mode does not advertise its teiid runtime-version
by Paul Richardson (JIRA)
[ https://issues.jboss.org/browse/TEIID-2650?page=com.atlassian.jira.plugin... ]
Paul Richardson commented on TEIID-2650:
----------------------------------------
I think that the upgrading of teiid on a domain member server to a different version of teiid to that on the domain master would be detrimental, would it not? For example, a new version of teiid might add a new translator or change its name and since this would be different from the master this would introduce a conflict.
Therefore, is it best to declare that teiid installations should remain uniform across a domain?
Ramesh, what do you think?
> A jboss server in domain mode does not advertise its teiid runtime-version
> --------------------------------------------------------------------------
>
> Key: TEIID-2650
> URL: https://issues.jboss.org/browse/TEIID-2650
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Paul Richardson
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 8.4.1, 8.5
>
>
> A standalone jboss server installed with teiid advertises its teiid runtime version at the path /subsystem=teiid/runtime-version.
> Likewise, a domain jboss server installed with teiid in the 'ha' profile should advertise its runtime version at the path /profile=ha/subsystem=teiid/runtime-version.
> However, whereas the standalone returns the correct value for this attribute, the domain mode server fails, only returning 'undefined'.
> This attribute is essential to designer in determining what version is the teiid instance. This in turns determines the functionality of the modelling that is available and which teiid client should be used for connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2656) Teiid OData Servlet throws java.lang.NullPointerException on every GET
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2656?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2656:
---------------------------------------
John a fix has been applied for 8.5 Final such that the original exception will be logged and you won't get this NPE. If you can build from master or if you want us to provide you with a test patch we could then see what is the root issue.
> Teiid OData Servlet throws java.lang.NullPointerException on every GET
> ----------------------------------------------------------------------
>
> Key: TEIID-2656
> URL: https://issues.jboss.org/browse/TEIID-2656
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.3, 8.4
> Environment: Windows 7 64 bit
> Oracle JDK 1.7.0 update 17
> JBoss AS 7.1.1 + Teiid 8.3 (both resteasy-jaxrs 2.3.5 and 2.3.7)
> JBoss EAP 6.1 + Teiid 8.4 (resteasy-jaxrs 2.3.6)
> Reporter: John Muller
> Assignee: Steven Hawkins
> Attachments: server.log
>
>
> A simple GET on any Teiid 8.3 or 8.4 OData ReST resource results in a Null Pointer:
> 11:43:20,166 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata].[Resteasy]] (http-localhost-127.0.0.1-8080-2) Servlet.service() for servlet Resteasy threw exception: java.lang.NullPointerException
> at com.ctc.wstx.sw.BaseStreamWriter.writeCharacters(BaseStreamWriter.java:447)
> at org.codehaus.stax2.ri.Stax2EventWriterImpl.add(Stax2EventWriterImpl.java:124)
> at org.odata4j.stax2.staximpl.StaxXMLWriter2.writeText(StaxXMLWriter2.java:108) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:]
> at org.odata4j.format.xml.AtomErrorFormatWriter.writeError(AtomErrorFormatWriter.java:31) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:]
> at org.odata4j.format.xml.AtomErrorFormatWriter.write(AtomErrorFormatWriter.java:20) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:]
> at org.odata4j.format.xml.AtomErrorFormatWriter.write(AtomErrorFormatWriter.java:15) [odata4j-core-0.8.0-SNAPSHOT-redhat.jar:]
> at org.teiid.odata.ODataExceptionMappingProvider.toResponse(ODataExceptionMappingProvider.java:55) [classes:]
> at org.teiid.odata.ODataExceptionMappingProvider.toResponse(ODataExceptionMappingProvider.java:42) [classes:]
> at org.jboss.resteasy.core.SynchronousDispatcher.executeExceptionMapper(SynchronousDispatcher.java:344) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.unwrapException(SynchronousDispatcher.java:373) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:362) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:233) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:209) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:557) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126) [resteasy-jaxrs-2.3.7.Final.jar:]
> at org.teiid.odata.ODataServletContainerDispatcher.service(ODataServletContainerDispatcher.java:97) [classes:]
> at org.teiid.odata.ODataServlet.service(ODataServlet.java:61) [classes:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.7.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:489) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Unknown Source) [rt.jar:1.7.0_17]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2650) A jboss server in domain mode does not advertise its teiid runtime-version
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/TEIID-2650?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on TEIID-2650:
-----------------------------------------
Ramesh,
Yes, DOMAIN_SERVER and STANDALONE_SERVER are both application server process types, as is EMBEDDED_SERVER. The distinctions reflect how the server lifecycle is controlled:
DOMAIN_SERVER -- separate process controlled by the HostController
STANDALONE_SERVER -- separate process controlled by the end user, typically via a launch script but not always, e.g. an Arquillian container could be managing the process programatically. But it's a separate process from the Arquillian container.
EMBEDDED_SERVER -- server is running inside another process
> A jboss server in domain mode does not advertise its teiid runtime-version
> --------------------------------------------------------------------------
>
> Key: TEIID-2650
> URL: https://issues.jboss.org/browse/TEIID-2650
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Paul Richardson
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 8.4.1, 8.5
>
>
> A standalone jboss server installed with teiid advertises its teiid runtime version at the path /subsystem=teiid/runtime-version.
> Likewise, a domain jboss server installed with teiid in the 'ha' profile should advertise its runtime version at the path /profile=ha/subsystem=teiid/runtime-version.
> However, whereas the standalone returns the correct value for this attribute, the domain mode server fails, only returning 'undefined'.
> This attribute is essential to designer in determining what version is the teiid instance. This in turns determines the functionality of the modelling that is available and which teiid client should be used for connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2650) A jboss server in domain mode does not advertise its teiid runtime-version
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/TEIID-2650?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on TEIID-2650:
-----------------------------------------
Paul,
To be precise, there is one *set* of Teiid configurations per domain. Different profiles in the domain can have different Teiid configurations. But yes, it is the responsibility of the domain management infrastructure to keep the domain wide configuration consistent across all Host Controllers in the domain, and that will include any Teiid subsystem configurations that exist. The Host Controllers ensure that servers gets a consistent representation of whatever portion of the domain wide config is relevant to that server.
Configuration is distinct from runtime state though. The actual binaries installed on different hosts can be different, and this runtime-version attribute reflects what actual binaries are being used for a process.
That doc, before getting into the teiid-domain-mode-install.cli script part, says
"To start the server in "Domain" mode, install the JBoss AS 7.2 (EAP 6.1) and Teiid 8.4 on all the servers that are going to be part of the cluster."
So there's a binary provisioning step that occurs before config gets applied. That doc focuses on an initial setup case where all hosts are almost certainly going to be running the same release. But once a domain is in active use, it's possible that some hosts will be upgraded to a later release while others will not.
> A jboss server in domain mode does not advertise its teiid runtime-version
> --------------------------------------------------------------------------
>
> Key: TEIID-2650
> URL: https://issues.jboss.org/browse/TEIID-2650
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Paul Richardson
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 8.4.1, 8.5
>
>
> A standalone jboss server installed with teiid advertises its teiid runtime version at the path /subsystem=teiid/runtime-version.
> Likewise, a domain jboss server installed with teiid in the 'ha' profile should advertise its runtime version at the path /profile=ha/subsystem=teiid/runtime-version.
> However, whereas the standalone returns the correct value for this attribute, the domain mode server fails, only returning 'undefined'.
> This attribute is essential to designer in determining what version is the teiid instance. This in turns determines the functionality of the modelling that is available and which teiid client should be used for connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2650) A jboss server in domain mode does not advertise its teiid runtime-version
by Paul Richardson (JIRA)
[ https://issues.jboss.org/browse/TEIID-2650?page=com.atlassian.jira.plugin... ]
Paul Richardson commented on TEIID-2650:
----------------------------------------
Brian,
Many thanks for that helpful information. It raises an interesting question though. In order to get teiid up and running, I use the [teiid-domain-mode-install.cli|https://docs.jboss.org/author/display/teiid...] script to install the teiid resources on the domain master. Thus, I think that would constitute domain-wide would it not?
Certainly, my domain member server inherits the teiid configuration from the domain master. It would seem that teiid is not merely a single application that is only deployed on member servers and in that sense 1 teiid configuration per domain?
> A jboss server in domain mode does not advertise its teiid runtime-version
> --------------------------------------------------------------------------
>
> Key: TEIID-2650
> URL: https://issues.jboss.org/browse/TEIID-2650
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Paul Richardson
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 8.4.1, 8.5
>
>
> A standalone jboss server installed with teiid advertises its teiid runtime version at the path /subsystem=teiid/runtime-version.
> Likewise, a domain jboss server installed with teiid in the 'ha' profile should advertise its runtime version at the path /profile=ha/subsystem=teiid/runtime-version.
> However, whereas the standalone returns the correct value for this attribute, the domain mode server fails, only returning 'undefined'.
> This attribute is essential to designer in determining what version is the teiid instance. This in turns determines the functionality of the modelling that is available and which teiid client should be used for connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2650) A jboss server in domain mode does not advertise its teiid runtime-version
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2650?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2650:
-------------------------------------
Brian, what would be the difference between DOMAIN_SERVER and STANDALONE_SERVER ? Are they both nodes?
> A jboss server in domain mode does not advertise its teiid runtime-version
> --------------------------------------------------------------------------
>
> Key: TEIID-2650
> URL: https://issues.jboss.org/browse/TEIID-2650
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Paul Richardson
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 8.4.1, 8.5
>
>
> A standalone jboss server installed with teiid advertises its teiid runtime version at the path /subsystem=teiid/runtime-version.
> Likewise, a domain jboss server installed with teiid in the 'ha' profile should advertise its runtime version at the path /profile=ha/subsystem=teiid/runtime-version.
> However, whereas the standalone returns the correct value for this attribute, the domain mode server fails, only returning 'undefined'.
> This attribute is essential to designer in determining what version is the teiid instance. This in turns determines the functionality of the modelling that is available and which teiid client should be used for connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2650) A jboss server in domain mode does not advertise its teiid runtime-version
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/TEIID-2650?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on TEIID-2650:
-----------------------------------------
Note that the Teiid subsystem should not be registering this attribute on host controllers, since those processes cannot provide the information.
When the Teiid Extension is initialized by the Host Controller, an ExtensionContext is passed in. ExtensionContenxt.getProcessType() allows the extension to know what type of process it is running in (DOMAIN_SERVER, EMBEDDED_SERVER, STANDALONE_SERVER, HOST_CONTROLLER, APPLICATION_CLIENT) so it can use that information to control what resources/attributes/operations it registers. Items that don't make sense for the given process type shouldn't be registered.
> A jboss server in domain mode does not advertise its teiid runtime-version
> --------------------------------------------------------------------------
>
> Key: TEIID-2650
> URL: https://issues.jboss.org/browse/TEIID-2650
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Paul Richardson
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 8.4.1, 8.5
>
>
> A standalone jboss server installed with teiid advertises its teiid runtime version at the path /subsystem=teiid/runtime-version.
> Likewise, a domain jboss server installed with teiid in the 'ha' profile should advertise its runtime version at the path /profile=ha/subsystem=teiid/runtime-version.
> However, whereas the standalone returns the correct value for this attribute, the domain mode server fails, only returning 'undefined'.
> This attribute is essential to designer in determining what version is the teiid instance. This in turns determines the functionality of the modelling that is available and which teiid client should be used for connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2650) A jboss server in domain mode does not advertise its teiid runtime-version
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/TEIID-2650?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on TEIID-2650:
-----------------------------------------
When you call
{code}
/profile=ha/subsystem=teiid:read-resource
{code}
you are asking the Host Controller you connected to for information about the *domain wide* configuration. The Host Controller could fill in information for runtime-version that is correct for it's own process, but it cannot provide information that's correct domain wide. There is no such thing as a domain wide runtime-version because it is perfectly legal to run multiple different versions on different hosts in a domain. It isn't required, or even expected in large domains, for all hosts to be on the same version. For example, different server groups might be running different applications, and if the behavior of some of those apps is acceptable domain managers may choose not to upgrade the hosts for those server groups when a new release comes out. Organizations are often quite conservative in this regard.
> A jboss server in domain mode does not advertise its teiid runtime-version
> --------------------------------------------------------------------------
>
> Key: TEIID-2650
> URL: https://issues.jboss.org/browse/TEIID-2650
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.4
> Reporter: Paul Richardson
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 8.4.1, 8.5
>
>
> A standalone jboss server installed with teiid advertises its teiid runtime version at the path /subsystem=teiid/runtime-version.
> Likewise, a domain jboss server installed with teiid in the 'ha' profile should advertise its runtime version at the path /profile=ha/subsystem=teiid/runtime-version.
> However, whereas the standalone returns the correct value for this attribute, the domain mode server fails, only returning 'undefined'.
> This attribute is essential to designer in determining what version is the teiid instance. This in turns determines the functionality of the modelling that is available and which teiid client should be used for connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months
[JBoss JIRA] (TEIID-2657) ava.lang.NoClassDefFoundError: org/jaxen/NamespaceContext
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2657?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2657.
-----------------------------------
Resolution: Rejected
Does not currently impact the community.
> ava.lang.NoClassDefFoundError: org/jaxen/NamespaceContext
> ---------------------------------------------------------
>
> Key: TEIID-2657
> URL: https://issues.jboss.org/browse/TEIID-2657
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.4.1
> Reporter: Van Halbert
> Assignee: Steven Hawkins
>
> When attempting to query an XML text file in ER1 I am getting A java.lang.NoClassDefFoundError: org/jaxen/NamespaceContext error:
> 14:03:13,829 ERROR [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2) TEIID30019 Unexpected exception for request Nob5JdZX4Frm.0: org.teiid.core.TeiidRuntimeException: org/jaxen/NamespaceContext
> at org.teiid.query.processor.relational.XMLTableNode$1.run(XMLTableNode.java:232) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:214) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0]
> Caused by: java.lang.NoClassDefFoundError: org/jaxen/NamespaceContext
> at nu.xom.NodeFactory.startMakingDocument(Unknown Source) [xom-1.2.7-redhat-3.jar:1.2.7-redhat-3]
> at nux.xom.xquery.StreamingPathFilter$StreamingPathFilterNodeFactory.startMakingDocument(StreamingPathFilter.java:389) [nux-1.6.jar:1.6]
> at nu.xom.XOMHandler.startDocument(Unknown Source) [xom-1.2.7-redhat-3.jar:1.2.7-redhat-3]
> at net.sf.saxon.event.ContentHandlerProxy.open(ContentHandlerProxy.java:261) [saxonhe-9.2.1.5.jar:]
> at org.teiid.query.xquery.saxon.ContentHandlerProxyReceiver.open(StreamingUtils.java:265) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> at net.sf.saxon.event.ProxyReceiver.open(ProxyReceiver.java:80) [saxonhe-9.2.1.5.jar:]
> at net.sf.saxon.event.ReceivingContentHandler.startDocument(ReceivingContentHandler.java:204) [saxonhe-9.2.1.5.jar:]
> at org.apache.xerces.parsers.AbstractSAXParser.startDocument(Unknown Source)
> at org.apache.xerces.impl.dtd.XMLDTDValidator.startDocument(Unknown Source)
> at org.apache.xerces.impl.XMLDocumentScannerImpl.startEntity(Unknown Source)
> at org.apache.xerces.impl.XMLVersionDetector.startDocumentParsing(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:397) [saxonhe-9.2.1.5.jar:]
> at net.sf.saxon.event.Sender.send(Sender.java:182) [saxonhe-9.2.1.5.jar:]
> at net.sf.saxon.Configuration.buildDocument(Configuration.java:3317) [saxonhe-9.2.1.5.jar:]
> at net.sf.saxon.Configuration.buildDocument(Configuration.java:3262) [saxonhe-9.2.1.5.jar:]
> at org.teiid.query.xquery.saxon.SaxonReader.parse(StreamingUtils.java:169) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> at nu.xom.Builder.build(Unknown Source) [xom-1.2.7-redhat-3.jar:1.2.7-redhat-3]
> at nu.xom.Builder.build(Unknown Source) [xom-1.2.7-redhat-3.jar:1.2.7-redhat-3]
> at org.teiid.query.xquery.saxon.XQueryEvaluator.evaluateXQuery(XQueryEvaluator.java:134) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> at org.teiid.query.processor.relational.XMLTableNode$1.run(XMLTableNode.java:226) [teiid-engine-8.4.1-redhat-1.jar:8.4.1-redhat-1]
> ... 6 more
> Caused by: java.lang.ClassNotFoundException: org.jaxen.NamespaceContext from [Module "org.jboss.teiid:main" from local module loader @4bce79b8 (finder: local module finder @609945e9 (roots: /home/wgibson/apps/DV6-ER1/PASS-FOUR/jboss-eap-6.1/modules,/home/wgibson/apps/DV6-ER1/PASS-FOUR/jboss-eap-6.1/modules/system/layers/ds,/home/wgibson/apps/DV6-ER1/PASS-FOUR/jboss-eap-6.1/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.0.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.0.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.0.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.0.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.0.Final-redhat-1]
> ... 31 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 3 months