November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-381) Add ability to provide a transformation to the MechanismAuthenticationFactory factory

by David Lloyd (JIRA)

David Lloyd created ELY-381: ------------------------------- Summary: Add ability to provide a transformation to the MechanismAuthenticationFactory factory Key: ELY-381 URL: https://issues.jboss.org/browse/ELY-381 Project: WildFly Elytron Issue Type: Task Components: API / SPI, HTTP, SASL Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta3 Add the ability to provide a {{UnaryOperator}} which transforms the factory used in a mechanism authetication factory before using it to create the mechanism instance. This will necessitate a new type parameter to {{MechanismAuthenticationFactory}} and its derivatives. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5479) rest api mashall object to json default not ignore null fileds

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-5479?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-5479: -------------------------------------- Assignee: Stuart Douglas (was: Kurt Stam) > rest api mashall object to json default not ignore null fileds > -------------------------------------------------------------- > > Key: WFLY-5479 > URL: https://issues.jboss.org/browse/WFLY-5479 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.0.0.Beta1, 10.0.0.Beta2, 10.0.0.CR1, 10.0.0.CR2 > Reporter: henry hu > Assignee: Stuart Douglas > Labels: jboss > Fix For: 10.0.0.CR5 > > > mashall object to Json default not ignore null fileds,but mashall to xml is ok . > "user": { > "id": 26357, > "gameId": null, > "userIds": null, > "userName": "testn008", > "status": 1, > "password": null, > "payPassword": null, > "qq": null, > "email": null, > "userType": 16, > "level": 0, > "subCompany": null, > "majorShareholder": null, > "sharehoder": null, > "majorAgent": null, > "agent": null, > "nickName": "sdfs", > "cellPhoneNumber": null, > "createTime": "2015-05-08 20:32:37", > "currency": "CNY", > "registerIp": "127.0.0.1", > "lastLoginIP": "127.0.0.1", > "lastLoginTime": 1444146936000, > "roles": [], > "roleIds": [], > "userCount": 0, > "fromId": null, > "fromUrl": null, > "hasUpdatePwd": 1, > "isSpread": 0, > "spreadType": null, > "parentUserName": null, > "memberCnt": null, > "serverTime": "2015-10-06 23:58:40" > }, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5479) rest api mashall object to json default not ignore null fileds

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-5479?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-5479: -------------------------------------- Assignee: (was: Stuart Douglas) > rest api mashall object to json default not ignore null fileds > -------------------------------------------------------------- > > Key: WFLY-5479 > URL: https://issues.jboss.org/browse/WFLY-5479 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 10.0.0.Beta1, 10.0.0.Beta2, 10.0.0.CR1, 10.0.0.CR2 > Reporter: henry hu > Labels: jboss > Fix For: 10.0.0.CR5 > > > mashall object to Json default not ignore null fileds,but mashall to xml is ok . > "user": { > "id": 26357, > "gameId": null, > "userIds": null, > "userName": "testn008", > "status": 1, > "password": null, > "payPassword": null, > "qq": null, > "email": null, > "userType": 16, > "level": 0, > "subCompany": null, > "majorShareholder": null, > "sharehoder": null, > "majorAgent": null, > "agent": null, > "nickName": "sdfs", > "cellPhoneNumber": null, > "createTime": "2015-05-08 20:32:37", > "currency": "CNY", > "registerIp": "127.0.0.1", > "lastLoginIP": "127.0.0.1", > "lastLoginTime": 1444146936000, > "roles": [], > "roleIds": [], > "userCount": 0, > "fromId": null, > "fromUrl": null, > "hasUpdatePwd": 1, > "isSpread": 0, > "spreadType": null, > "parentUserName": null, > "memberCnt": null, > "serverTime": "2015-10-06 23:58:40" > }, -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1162) Need ResourceTransformationDescriptionBuilder.addChildRedirection(...) variant with a DynamicDiscardPolicy

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1162?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1162: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 > Need ResourceTransformationDescriptionBuilder.addChildRedirection(...) variant with a DynamicDiscardPolicy > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1162 > URL: https://issues.jboss.org/browse/WFCORE-1162 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Affects Versions: 2.0.2.Final > Reporter: Paul Ferraro > Assignee: Kabir Khan > Fix For: 3.0.0.Alpha1 > > > The Infinispan subsystem has a need to use Need ResourceTransformationDescriptionBuilder.addChildRedirection(...) variant with a DynamicDiscardPolicy to more accurately support transformation of auto-created child resources. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5603) Get data source information

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-5603?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-5603: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > Get data source information > --------------------------- > > Key: WFLY-5603 > URL: https://issues.jboss.org/browse/WFLY-5603 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Jesper Pedersen > Assignee: Lin Gao > Fix For: 11.0.0.Alpha1 > > > Create a DMR operation that returns the available properties for the data source class, and xa data source class for the <driver> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-5644) EJB timers should use a different logging category to separate it from other EJB invocations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-5644?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-5644: ----------------------------------- Fix Version/s: 11.0.0.Alpha1 > EJB timers should use a different logging category to separate it from other EJB invocations > -------------------------------------------------------------------------------------------- > > Key: WFLY-5644 > URL: https://issues.jboss.org/browse/WFLY-5644 > Project: WildFly > Issue Type: Feature Request > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Labels: ejb, timer, timers, timerservice > Fix For: 11.0.0.Alpha1 > > > To analyze timer behaviour or track issues related to timers sometimes a log level higher than INFO is needed. > Unfortunately the category "org.jboss.as.ejb3" does not make a differenciation and setting this category to DEBUG or TRACE cause a high amount of log messages, this can have performance impacts and make it dfficult to handle and read the logfiles. > It should be possible to have a separate category for timers. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4591) Memory leak inPerThreadTagHandlerPool | Wildfly 8.2.0.Final (Undertow)

by Cosmin Stroe (JIRA)

[ https://issues.jboss.org/browse/WFLY-4591?page=com.atlassian.jira.plugin.... ] Cosmin Stroe commented on WFLY-4591: ------------------------------------ We have ran into the same memory leak in Wildfly 8.2.0.Final, but we are not able to use your attached Jastow JAR, as there are incompatible changes: {code:java} ^[[0m^[[31m14:27:38,793 ERROR MSC service thread 1-1 [fail] MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host/syncstorer.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./syncstorer.UndertowDeploymentInfoService: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoSuchMethodError: io.undertow.jsp.JspServletBuilder.setupDeployment(Lio/undertow/servlet/api/DeploymentInfo;Ljava/util/HashMap;Ljava/util/HashMap;Lorg/apache/tomcat/InstanceManager;)V at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:577) at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:256) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) ... 3 more {code} How were you able to fix this memory leak? Is there a workaround? > Memory leak inPerThreadTagHandlerPool | Wildfly 8.2.0.Final (Undertow) > ---------------------------------------------------------------------- > > Key: WFLY-4591 > URL: https://issues.jboss.org/browse/WFLY-4591 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.2.0.Final > Environment: CentOS release 6.5 (Final), java version "1.7.0_71" 64 bit VM, Wildfly 8.2.0.Final, Min heap and Max heap 1536m > > Reporter: Srivathsan Agaram Venkatavaradhan > Assignee: Tomaz Cerar > Labels: garbage, jastow, undertow, wildfly > Fix For: 10.0.0.Alpha3 > > Attachments: jastow-2.0.0-SNAPSHOT.jar > > > We upgraded from Jboss 7.1.1.Final to Wildfly 8.2.0.Final. After the upgrade we are seeing full frequent garbage collection (happening every 2 mins) during load test. This was not the case in Jboss 7.1.1.Final. Our heap dumps suggested that there is huge memory leak with > org.apache.jasper.runtime.BodyContentImpl. This is part of JSP runtime (jastow). On analysis we found that undertow uses default as PerThreadTagHanlderPool. By changing this to TagHanlderPool, this issue seems to vanish. > diff --git a/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java b/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java > index eaa8560..c6c785f 100644 > --- a/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java > +++ b/src/main/java/org/apache/jasper/runtime/TagHandlerPool.java > @@ -53,7 +53,7 @@ public class TagHandlerPool { > result = null; > } > } > - if( result==null ) result=new PerThreadTagHandlerPool(); > + if( result==null ) result=new TagHandlerPool(); > result.init(config); > > return result; > - See more at: https://developer.jboss.org/message/927538#927538 > I think this issue may be related to https://issues.jboss.org/browse/WFLY-4617 as there were huge garbage created and most of the contents were char array (rendered html). May be TagHanlderPool is creating more char instead of reusing from pool. Please provide thoughts. I can share, heapdump or MAT screenshots if needed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1174) Management Model not refreshed on changes

by Guillermo González de Agüero (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1174?page=com.atlassian.jira.plugi... ] Guillermo González de Agüero closed WFCORE-1174. ------------------------------------------------ Resolution: Done Sorry, I wanted to open this issue on the HAL project. > Management Model not refreshed on changes > ----------------------------------------- > > Key: WFCORE-1174 > URL: https://issues.jboss.org/browse/WFCORE-1174 > Project: WildFly Core > Issue Type: Enhancement > Reporter: Guillermo González de Agüero > > It seems to make only one request per resource. Would be really nice if it can be updated on configuration changes, as it does on the console when changes are done via the model. > Extended steps: > - Start WildFly > - Go to Configuration and create a new interface: "new-interface". > - Open the Management Model and click on "interfaces". It issues a request and "new-interface" interface is present. > - Now create another interface: "newer-interface". > - Go again to the Management Model. "newer-interface" is not there. You have to manually refresh the model in order to see it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1174) Management Model not refreshed on changes

by Guillermo González de Agüero (JIRA)

Guillermo González de Agüero created WFCORE-1174: ---------------------------------------------------- Summary: Management Model not refreshed on changes Key: WFCORE-1174 URL: https://issues.jboss.org/browse/WFCORE-1174 Project: WildFly Core Issue Type: Enhancement Reporter: Guillermo González de Agüero It seems to make only one request per resource. Would be really nice if it can be updated on configuration changes, as it does on the console when changes are done via the model. Extended steps: - Start WildFly - Go to Configuration and create a new interface: "new-interface". - Open the Management Model and click on "interfaces". It issues a request and "new-interface" interface is present. - Now create another interface: "newer-interface". - Go again to the Management Model. "newer-interface" is not there. You have to manually refresh the model in order to see it. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-1161) Simplification of setCapabilityReference where resource only exposes a single capability.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1161?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1161: ------------------------------------- Fix Version/s: 3.0.0.Alpha1 > Simplification of setCapabilityReference where resource only exposes a single capability. > ----------------------------------------------------------------------------------------- > > Key: WFCORE-1161 > URL: https://issues.jboss.org/browse/WFCORE-1161 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha1 > > > Currently we need to use the following method to specify that one of our attributes is a reference to another capability: - > {code} > public BUILDER setCapabilityReference(String referencedCapability, String dependentCapability, boolean dynamicDependent) { > referenceRecorder = new CapabilityReferenceRecorder.DefaultCapabilityReferenceRecorder(referencedCapability, dependentCapability, dynamicDependent); > return (BUILDER) this; > } > {code} > However the resource has already indicated the capability it provides and indicated whether it is dynamic so the last two parameters duplicate this information. > This makes it much harder to re-use attribute definitions across different resources as even though they may reference the same time they now contain information about the resource they are used within. > As discussed previously there is still the case that a single resource could provide multiple capabilities and this additional information may be required to clarify which capability it is in relation to but in general if a resource only provides a single capability we should be able to detect that without the additional information on the attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015