[JBoss JIRA] (WFLY-4126) java.lang.ExceptionInInitializerError when invoking BIRT service
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4126?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4126.
----------------------------------
Resolution: Rejected
I can't reproduce, and can't see how this could happen with our ExpressionFactory implementation.
The most likely cause is something in the deployment providing an ExpressionFactory implementation that returns null for getStreamELResolver
> java.lang.ExceptionInInitializerError when invoking BIRT service
> ----------------------------------------------------------------
>
> Key: WFLY-4126
> URL: https://issues.jboss.org/browse/WFLY-4126
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 and JDK 1.8
> Reporter: Chezy Palani
> Assignee: Stuart Douglas
> Attachments: server.log.2014-11-25
>
>
> There was no error during the deployment of the Application. Even hitting landing page works fine. When our service is invoked, we get this exception.
> Context Path:
> /actuatejavacomponent
> Servlet Path:
> /iv
> Path Info:
> null
> Query String:
> __report=%2fPublic%2fBIRT%20and%20BIRT%20Studio%20Examples%2fCustomer%20Dashboard%2erptdocument&closex=true&__vp=workgroup&showBanner=true&showBreadCrumb=false&locale=en_US
> Stack Trace
> javax.servlet.ServletException: java.lang.ExceptionInInitializerError
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchToServlet(ServletInitialHandler.java:198)
> io.undertow.servlet.spec.RequestDispatcherImpl.include(RequestDispatcherImpl.java:279)
> com.actuate.iv.presentation.aggregation.IVBaseFragment.service(IVBaseFragment.java:261)
> com.actuate.iv.servlet.IVHttpDispatcher.handleRequest(IVHttpDispatcher.java:144)
> com.actuate.iv.servlet.IVServlet.doGet(IVServlet.java:261)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63)
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
> io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261)
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247)
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166)
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:197)
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759)
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-73) NPE in RootResourceIterator
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-73?page=com.atlassian.jira.plugin.sy... ]
RH Bugzilla Integration updated WFLY-73:
----------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1185118
> NPE in RootResourceIterator
> ---------------------------
>
> Key: WFLY-73
> URL: https://issues.jboss.org/browse/WFLY-73
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, JMX
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Alpha1
>
>
> Intermittent testsuite failures, e.g.
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/as7-param-pull/684...
> Log shows this repeatedly:
> [0m[33m18:38:11,612 WARN [org.jboss.remotingjmx.protocol.v2.ServerCommon] (pool-2-thread-12) Unexpected internal error: java.lang.NullPointerException
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:49)
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:55)
> at org.jboss.as.jmx.model.RootResourceIterator.doIterate(RootResourceIterator.java:55)
> at org.jboss.as.jmx.model.RootResourceIterator.iterate(RootResourceIterator.java:39)
> at org.jboss.as.jmx.model.ModelControllerMBeanHelper.getMBeanCount(ModelControllerMBeanHelper.java:103)
> at org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.getMBeanCount(ModelControllerMBeanServerPlugin.java:116)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanCount(PluggableMBeanServerImpl.java:220)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$GetMBeanCountHandler.handle(ServerProxy.java:618)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_13]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_13]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_13]
> RootResourceIterator.doIterate is reading the resource twice:
> {code}
> for (ResourceEntry entry : current.getChildren(type)) {
> final PathElement pathElement = entry.getPathElement();
> final Resource child = current.getChild(pathElement); // why this call since "entry" and "child" should be the same object
> final PathAddress childAddress = address.append(pathElement);
> doIterate(child, childAddress);
> }
> {code}
> The problem is "child" is null, which is possible with a dynamic resource. So, either "entry" should be used, or, if there is some reason for the 2nd read, a check for null is needed before the recursive doIterate call.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-1366) @DataSourceDefinition incorrectly requires other properties than name and class-name
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-1366?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski reassigned WFLY-1366:
------------------------------------
Assignee: (was: Tomasz Adamski)
> @DataSourceDefinition incorrectly requires other properties than name and class-name
> ------------------------------------------------------------------------------------
>
> Key: WFLY-1366
> URL: https://issues.jboss.org/browse/WFLY-1366
> Project: WildFly
> Issue Type: Feature Request
> Components: EE
> Affects Versions: 8.0.0.Alpha1
> Reporter: arjan tijms
> Labels: spec, validation
>
> When using the <data-source> element in e.g. web.xml or application.xml JBoss EAP 6.0.1/JBoss AS 7.1.3 does not accept a configuration without properties other than {{name}} and {{class-name}}. For instance:
> {code:xml}
> <data-source>
> <name>java:app/myDS</name>
> <class-name>com.example.MyDS</class-name>
> </data-source>
> {code}
> With such configuration, the following exception is thrown:
> {noformat}
> Caused by: org.jboss.jca.common.api.validator.ValidateException: IJ010069: Missing required element xa-datasource-property in org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl
> at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.validate(XADataSourceImpl.java:385)
> at org.jboss.jca.common.metadata.ds.v10.XADataSourceImpl.<init>(XADataSourceImpl.java:116)
> at org.jboss.jca.common.metadata.ds.v11.XADataSourceImpl.<init>(XADataSourceImpl.java:76)
> at org.jboss.as.connector.subsystems.datasources.ModifiableXaDataSource.getUnModifiableInstance(ModifiableXaDataSource.java:373)
> at org.jboss.as.connector.subsystems.datasources.XaDataSourceService.getDeployer(XaDataSourceService.java:70)
> at org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.start(AbstractDataSourceService.java:116)
> {noformat}
> At the point where the exception is thrown, the code checks if there are any properties at all:
> {code}
> if (this.xaDataSourceProperty.isEmpty())
> throw new ValidateException(
> bundle.requiredElementMissing(
> Tag.XA_DATASOURCE_PROPERTY.getLocalName(),
> this.getClass().getCanonicalName()));
> {code}
> I don't understand why this check is there. If I'm not mistaken the spec (e.g. JSR 250 section 2.13 and JSR 316 section EE.5.17) does not seem to mandate properties to be present and the corresponding annotation only requires {{name}} and {{className}} to be specified.
> A workaround is to subclass the data source class and provide a dummy property, e.g.
> {code:xml}
> <data-source>
> <name>java:app/myDS</name>
> <class-name>com.example.MySubDS</class-name>
> <property>
> <name>dummy</name>
> <value>dummy</value>
> </property>
> </data-source>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4174) Xalan Linkage error : TransformerConfigurationException
by Stephen Kay (JIRA)
[ https://issues.jboss.org/browse/WFLY-4174?page=com.atlassian.jira.plugin.... ]
Stephen Kay edited comment on WFLY-4174 at 1/22/15 5:03 PM:
------------------------------------------------------------
If you are embeeding XML implementation in your app (have a look in your jars), you'll not encounter that bug / but face risks of side effects / depending on xml impl version. I would say : you should not embeed an XML impl / though by chance this is working ok / like my workaround.
Now Infinitispan's is using Wildfly's buggy Xalan module with DistributedExecutorService. And when distributing objects over clusters, this issue is occuring,
So according your issue, this means a blocking bug for infinityspan in cluster mode.
David : should we set priority as "blocker" ?
was (Author: skay088):
If you are embeeding XML implementation in your app (have a look in your jars), you'll not encounter that bug / but face risks of side effects / depending on xml impl version (so you should not / but by chance this is working ok / like my workaround).
Now Infinitispan's is using Wildfly's buggy Xalan module with DistributedExecutorService. And when distributing objects over clusters, this issue is occuring,
So according your issue, this means a blocking bug for infinityspan in cluster mode.
David : should we set priority as "blocker" ?
> Xalan Linkage error : TransformerConfigurationException
> -------------------------------------------------------
>
> Key: WFLY-4174
> URL: https://issues.jboss.org/browse/WFLY-4174
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.1 & 8.2-Final
> JDK 1.7.0_45 & 1.7.0_71
> Windows & Linux
> Reporter: Stephen Kay
> Assignee: David Lloyd
> Priority: Critical
>
> Please note that this bug wasn't present on JBoss 7.1 / same WAR artifact
> This is full staktrace from our applicaion.
> 11:13:32,130 SEVERE ch.mitsa.credoc.ui.views.messages.MessagesTable (default task-9) Error getting message payload: : javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:765) rt.jar:1.7.0_71
> at _redirected.TransformerFactory.newTransformer(_TransformerFactory.java:132) jboss-modules.jar:1.3.3.Final
> at ch.mitsa.credoc.format.swift.impl.SwiftFormatter.getPrettyPrintedPayload(SwiftFormatter.java:196)
> at ch.mitsa.credoc.engine.service.OutputService.getPrettyPrintedMessage(OutputService.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) rt.jar:1.7.0_71
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) rt.jar:1.7.0_71
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) rt.jar:1.7.0_71
> at java.lang.reflect.Method.invoke(Method.java:606) rt.jar:1.7.0_71
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) wildfly-weld-8.2.0.Final.jar:8.2.0.Final
> (...)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4174) Xalan Linkage error : TransformerConfigurationException
by Stephen Kay (JIRA)
[ https://issues.jboss.org/browse/WFLY-4174?page=com.atlassian.jira.plugin.... ]
Stephen Kay commented on WFLY-4174:
-----------------------------------
If you are embeeding XML implementation in your app (have a look in your jars), you'll not encounter that bug / but face risks of side effects / depending on xml impl version (so you should not / but by chance this is working ok / like my workaround).
Now Infinitispan's is using Wildfly's buggy Xalan module with DistributedExecutorService. And when distributing objects over clusters, this issue is occuring,
So according your issue, this means a blocking bug for infinityspan in cluster mode.
David : should we set priority as "blocker" ?
> Xalan Linkage error : TransformerConfigurationException
> -------------------------------------------------------
>
> Key: WFLY-4174
> URL: https://issues.jboss.org/browse/WFLY-4174
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.1 & 8.2-Final
> JDK 1.7.0_45 & 1.7.0_71
> Windows & Linux
> Reporter: Stephen Kay
> Assignee: David Lloyd
> Priority: Critical
>
> Please note that this bug wasn't present on JBoss 7.1 / same WAR artifact
> This is full staktrace from our applicaion.
> 11:13:32,130 SEVERE ch.mitsa.credoc.ui.views.messages.MessagesTable (default task-9) Error getting message payload: : javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418) rt.jar:1.7.0_71
> at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformer(TransformerFactoryImpl.java:765) rt.jar:1.7.0_71
> at _redirected.TransformerFactory.newTransformer(_TransformerFactory.java:132) jboss-modules.jar:1.3.3.Final
> at ch.mitsa.credoc.format.swift.impl.SwiftFormatter.getPrettyPrintedPayload(SwiftFormatter.java:196)
> at ch.mitsa.credoc.engine.service.OutputService.getPrettyPrintedMessage(OutputService.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) rt.jar:1.7.0_71
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) rt.jar:1.7.0_71
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) rt.jar:1.7.0_71
> at java.lang.reflect.Method.invoke(Method.java:606) rt.jar:1.7.0_71
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:407)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) wildfly-weld-8.2.0.Final.jar:8.2.0.Final
> (...)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-1077) JDK ORB Subsystem
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-1077?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-1077:
--------------------------------------
Jacorb directory is still present after merge - it should be removed: created https://issues.jboss.org/browse/WFLY-4284 to address this.
> JDK ORB Subsystem
> -----------------
>
> Key: WFLY-1077
> URL: https://issues.jboss.org/browse/WFLY-1077
> Project: WildFly
> Issue Type: Feature Request
> Components: IIOP
> Reporter: Dimitris Andreadis
> Assignee: Tomasz Adamski
>
> Implement a JDK ORB subsystem that can act as a replacement for the JacORB subsystem.
> AFAIK, most/all JDK ORBs are based on the Sun ORB.
> Ideally the 2 ORBs (JDK & JacORB) would be both supported in case we need to go through a transition period, or we need to support a particular interop scenario for which interop communication has issues.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months