[JBoss JIRA] (WFCORE-3612) CDI service loader problems
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3612?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-3612:
-------------------------------
Reporter: Kabir Khan (was: Ken Finnigan)
> CDI service loader problems
> ---------------------------
>
> Key: WFCORE-3612
> URL: https://issues.jboss.org/browse/WFCORE-3612
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.8.Final
> Reporter: Kabir Khan
> Assignee: David Lloyd
> Priority: Blocker
> Fix For: 4.0.0.Alpha10, 3.1.0.Final
>
>
> Within WildFly Swarm we need the ability to override the `javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom handling for implementing Eclipse MicroProfile.
> With a service file present in the deployment, the existing RESTEasy service file is always found first because the deployment module is added as a dependency after other non local dependencies. See https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution was for the deployment's dependency to always be first if `isLocalLast()` is false, and instead remove any spec packages that might be present on the deployment path instead.
> He explained the purpose of this ordering was to prevent a user deploying `javax.servlet.api` and breaking things, but it appears this can be achieved by alternative methods.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3612) Module dependency order for a deployment is wrong
by Kabir Khan (JIRA)
Kabir Khan created WFCORE-3612:
----------------------------------
Summary: Module dependency order for a deployment is wrong
Key: WFCORE-3612
URL: https://issues.jboss.org/browse/WFCORE-3612
Project: WildFly Core
Issue Type: Bug
Affects Versions: 3.0.8.Final
Reporter: Ken Finnigan
Assignee: David Lloyd
Priority: Blocker
Fix For: 4.0.0.Alpha10, 3.1.0.Final
Within WildFly Swarm we need the ability to override the `javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom handling for implementing Eclipse MicroProfile.
With a service file present in the deployment, the existing RESTEasy service file is always found first because the deployment module is added as a dependency after other non local dependencies. See https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution was for the deployment's dependency to always be first if `isLocalLast()` is false, and instead remove any spec packages that might be present on the deployment path instead.
He explained the purpose of this ordering was to prevent a user deploying `javax.servlet.api` and breaking things, but it appears this can be achieved by alternative methods.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9835) Performance issues in WildFly11 as my 90% for jmeter run gets increased to 2x for same set of run as it was in Jboss.
by nilesh ratta (JIRA)
[ https://issues.jboss.org/browse/WFLY-9835?page=com.atlassian.jira.plugin.... ]
nilesh ratta updated WFLY-9835:
-------------------------------
Component/s: Server
> Performance issues in WildFly11 as my 90% for jmeter run gets increased to 2x for same set of run as it was in Jboss.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9835
> URL: https://issues.jboss.org/browse/WFLY-9835
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: nilesh ratta
> Assignee: Jason Greene
> Attachments: J-img3.png, J_img1.png, J_img2.png, Jboss_GClog.png, W_img1.png, W_img2.png, W_img3.png, WildFly11_GCLog.png
>
>
> I have upgraded my application from Jboss6 with java 6 to WildFly11 with java 8 in dev environment.
> Note :
> I am facing some performance issues in WildFly11 as my 90% gets increased for same set of run as it was in Jboss.
> *And minor GC gets increased to 7 times as it was in jboss.*
> And there is no application level code changes in wildfly11.
> *Please find attached files for GC log and Heap dump related inputs.*
> Inputs :
> JVM parameters : Parallel GC with 4 threads , -Xmx6144m Xmx6144m -XX:NewRatio=1 -XX:ParallelGCThreads=4 -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=1024m
> Parameters are same in Jboss 6 and WildFly11.
> Jmeter result overview for 100 users in 15 mnts with 250 sec rampup time.
> As all of our app server is on AWS with same configuration.
> 1. Jboss 6 results :
> Label Count Average 90%_line Min Max Error% ThroughPut
> TOTAL 48664 167 418 0 30374 0 53.80
> 2. WildFLy11 results :
> Label Count Average 90%_line Min Max Error% ThroughPut
> TOTAL 54775 287 887 0 14286 0 60.672
> Note : As my count nd throughput increases but my* 90% is > 2x * for WildFly11.
> Kindly find the attached files for Heap dump as follows with following names in .png format:-
> For WildFly 11 :
> 1. W_img1.png :-
> WildFly11_DominatorTree : io.netty.buffer.PoolChunk ?????
> 2. W_img2.png
> WildFly_Histogram : Class Name| Objects | Shallow Heap | Retained Heap
> byte[] | 53,925 | 163,144,832 | >= 163,144,832
> 3. W_img3.png
> WildFly_Immediate Dominators for byte [] :
> For Jboss -6
>
> 1. J_img1.png :-
> Jboss6_DominatorTree : as there is no io.netty.buffer.PoolChunk .....
> 2. J_img2.png :-
> Jboss6_Histogram
> 3. J_img3.png :
> Jboss6_Immediate Dominators for byte [] :
>
> Kindly find GC log images for wildFly 11 and jboss 6 .for 15 mnts load run .
> Wildfly 11 Jboss 6
>
> Total GC 1162 174
> Total GC Time >21 sec 6 sec
> Total Reclaimed Bytes 3.32 tb 480 gb
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9837) Cannot register web service, fails with NullPointerException in DelegateClassLoader
by Antonio Chirizzi (JIRA)
Antonio Chirizzi created WFLY-9837:
--------------------------------------
Summary: Cannot register web service, fails with NullPointerException in DelegateClassLoader
Key: WFLY-9837
URL: https://issues.jboss.org/browse/WFLY-9837
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 11.0.0.Final
Reporter: Antonio Chirizzi
Assignee: Alessio Soldano
While deploying a EAR application, which contains a WAR which is trying to register a web service, I get the follwing exception:
{code}
13:53:34,624 INFO [org.jboss.ws.cxf.deployment] (MSC service thread 1-7) JBWS024074: WSDL published to: file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/standalone/data/wsdl/dms-new-ear-services-0.0.8.1.ear/dms-new-war-0.0.7.1.war/BusinessWebServiceService.wsdl
13:53:34,658 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/jboss/ws/jaxws-client/main/jbossws-cxf-client-5.1.9.Final.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
13:53:34,659 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-tools-wsdlto-frontend-jaxws-3.1.12.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
13:53:34,659 WARNING [org.apache.cxf.catalog.OASISCatalogManager] (MSC service thread 1-7) Catalog found at jar:file:/home/achirizzi/sandbox/dev/wildfly/wildfly-11.0.0.Final/modules/system/layers/base/org/apache/cxf/impl/main/cxf-services-ws-discovery-api-3.1.12.jar!/META-INF/jax-ws-catalog.xml but no org.apache.xml.resolver.CatalogManager was found. Check the classpatch for an xmlresolver jar.
13:53:34,773 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."dms-new-ear-services-0.0.8.1.ear"."dms-new-war-0.0.7.1.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.subunit."dms-new-ear-services-0.0.8.1.ear"."dms-new-war-0.0.7.1.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of subdeployment "dms-new-war-0.0.7.1.war" of deployment "dms-new-ear-services-0.0.8.1.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.xml.parsers.FactoryConfigurationError: Provider __redirected.__DocumentBuilderFactory could not be instantiated: java.lang.NullPointerException
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:204)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:152)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:232)
at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:120)
at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(WSDLReaderImpl.java:2180)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2390)
at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:2422)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:238)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:163)
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:85)
at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:217)
at org.apache.cxf.jaxws.ServiceImpl.initialize(ServiceImpl.java:160)
at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:129)
at org.jboss.wsf.stack.cxf.client.ProviderImpl$JBossWSServiceImpl.<init>(ProviderImpl.java:574)
at org.jboss.wsf.stack.cxf.client.ProviderImpl.createServiceDelegate(ProviderImpl.java:258)
at javax.xml.ws.Service.<init>(Service.java:57)
at com.tullettprebon.dms.tmmalternativeaddress.ws.TMMMarkitWireService.<init>(TMMMarkitWireService.java:60)
at com.tullettprebon.dms.webservices.ReferenceWebService.<init>(ReferenceWebService.java:232)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at org.jboss.wsf.stack.cxf.configuration.BusHolder.newInstance(BusHolder.java:322)
at org.jboss.wsf.stack.cxf.configuration.BusHolder.configure(BusHolder.java:212)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.startDeploymentBus(BusDeploymentAspect.java:97)
at org.jboss.wsf.stack.cxf.deployment.aspect.BusDeploymentAspect.start(BusDeploymentAspect.java:59)
at org.jboss.as.webservices.deployers.AspectDeploymentProcessor.deploy(AspectDeploymentProcessor.java:73)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
... 5 more
Caused by: java.lang.NullPointerException
at org.jboss.ws.common.utils.DelegateClassLoader.getResourceAsStream(DelegateClassLoader.java:132)
at __redirected.__RedirectedUtils.findProviderClassNames(__RedirectedUtils.java:147)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:102)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:98)
at __redirected.__DocumentBuilderFactory.<init>(__DocumentBuilderFactory.java:103)
at sun.reflect.GeneratedConstructorAccessor62.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:192)
... 33 more
{code}
I wasted 3 days trying to find a solution thinking that the problem was in my dependencies with xerces or any other xml resolver.
Then I decided to checkout the code near the root cause:
{code}
Caused by: java.lang.NullPointerException
at org.jboss.ws.common.utils.DelegateClassLoader.getResourceAsStream(DelegateClassLoader.java:132)
at __redirected.__RedirectedUtils.findProviderClassNames(__RedirectedUtils.java:147)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:102)
at __redirected.__RedirectedUtils.loadProvider(__RedirectedUtils.java:98)
at __redirected.__DocumentBuilderFactory.<init>(__DocumentBuilderFactory.java:103)
at sun.reflect.GeneratedConstructorAccessor62.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:192)
... 33 more
{code}
and I think I have fixed a bug in {{jbossws-common-3.1.5}}.
I have downloaded the latest version of {{jbossws-common-master}} from github (with which the problem was still showing).
Then I fixed the class {{org/jboss/ws/common/utils/DelegateClassLoader.java}} changing this:
{code}
/** {@inheritDoc} */
@Override
public InputStream getResourceAsStream(final String name)
{
InputStream is = parent.getResourceAsStream(name);
return (is == null) ? delegate.getResourceAsStream(name) : is;
}
{code}
to this:
{code}
/** {@inheritDoc} */
@Override
public InputStream getResourceAsStream(final String name)
{
InputStream is = null;
if (parent != null)
{
is = parent.getResourceAsStream(name);
}
return (is == null) ? delegate.getResourceAsStream(name) : is;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3611) (7.1.2) Attribute required-attributes of Elytron x500-attribute-principal-decoder cannot be added to configuration, doing this via management API leads to server stop
by Brad Maxwell (JIRA)
Brad Maxwell created WFCORE-3611:
------------------------------------
Summary: (7.1.2) Attribute required-attributes of Elytron x500-attribute-principal-decoder cannot be added to configuration, doing this via management API leads to server stop
Key: WFCORE-3611
URL: https://issues.jboss.org/browse/WFCORE-3611
Project: WildFly Core
Issue Type: Bug
Components: Security
Affects Versions: 4.0.0.Alpha10
Reporter: Brad Maxwell
Assignee: Yeray Borges
Priority: Blocker
When attribute {{required-attributes}} of Elytron x500-attribute-principal-decoder is added in CLI command then it fails with UnsupportedOperationException:
{code}
/subsystem=elytron/x500-attribute-principal-decoder=x500-decoder:add(attribute-name=cn,required-attributes=[cn])
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.UnsupportedOperationException",
"rolled-back" => true
}
{code}
Complete stack trace: -
{noformat}
13:03:44,179 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("x500-attribute-principal-decoder" => "x500-decoder")
]): java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)
at java.util.AbstractList.add(AbstractList.java:108)
at java.util.AbstractCollection.addAll(AbstractCollection.java:344)
at org.wildfly.extension.elytron.PrincipalDecoderDefinitions$2.getValueSupplier(PrincipalDecoderDefinitions.java:196)
at org.wildfly.extension.elytron.PrincipalDecoderDefinitions$PrincipalDecoderAddHandler.performRuntime(PrincipalDecoderDefinitions.java:293)
at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:325)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:982)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:726)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1408)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months