January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-1182) Update testsuite to run under Hudson

by Richard Achmatowicz (JIRA)

Update testsuite to run under Hudson -------------------------------------- Key: JBREM-1182 URL: https://jira.jboss.org/jira/browse/JBREM-1182 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.3.SP1 Reporter: Richard Achmatowicz Fix For: 2.2.3.SP2 Update the JBoss Remoting testsuite to run under Hudson. Some current problems include: (i) on Linux, JRunit based tests are failing due to members not finding each other (ii) on Linux, under JDK6, JRunit based tests are not able to create a JGroups stack (iii) JRunit system properties specified by the user on the command line are not being passed the the JUnit targets correctly, and so have no effect on the tests -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
25
0 / 0

[JBoss JIRA] Created: (JBAS-8771) Async log handler doesn't work

by David Lloyd (JIRA)

Async log handler doesn't work ------------------------------ Key: JBAS-8771 URL: https://issues.jboss.org/browse/JBAS-8771 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Reporter: David Lloyd Assignee: David Lloyd Fix For: 6.0.0.Final Async log handler doesn't work. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-8389) Issue in using ThreadLocal

by Arunsakthi Kalyanasundharam (JIRA)

Issue in using ThreadLocal -------------------------- Key: JBAS-8389 URL: https://jira.jboss.org/browse/JBAS-8389 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Java EE APIs Affects Versions: JBossAS-4.2.2.GA Environment: Application Server - Garbage collection Reporter: Arunsakthi Kalyanasundharam Assignee: Shelly McGowan Fix For: JBossAS-4.2.3.GA I'm using Threadlocal in a web component. By definition, threadlocal variables should be cleared by end of execution of the thread. In case Application server, since its using a thread pool, the threadlocal variables are not cleared / garbage collected. This is leading to memory leakage (out of memory errors) and inconsistent behavior of the application since the variables are not getting cleared off. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-5559) Example MC configuration for JBossCache instance with JDBCCacheLoader

by Galder Zamarreno (JIRA)

Example MC configuration for JBossCache instance with JDBCCacheLoader --------------------------------------------------------------------- Key: JBAS-5559 URL: http://jira.jboss.com/jira/browse/JBAS-5559 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation, JBoss Cache Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Priority: Minor Include an example on how to configure a JBossCache instance's JDBCCacheLoader via MC. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-8837) Clean up the max-threads attribute in managment socket config

by Brian Stansberry (JIRA)

Clean up the max-threads attribute in managment socket config ------------------------------------------------------------- Key: JBAS-8837 URL: https://issues.jboss.org/browse/JBAS-8837 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Priority: Minor Fix For: 7.0.0.Beta1 There is a max-threads field in the dc/host/server management socket config. It's not in the schema and AFAICT it's not used. Either use it and add to the schema, or remove it. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-8825) Default interface for a socket binding should come via SocketBindingManagerService

by Brian Stansberry (JIRA)

Default interface for a socket binding should come via SocketBindingManagerService ---------------------------------------------------------------------------------- Key: JBAS-8825 URL: https://issues.jboss.org/browse/JBAS-8825 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Assignee: Emanuel Muckenhuber Fix For: 7.0.0.Beta1 The default interface used for socket bindings comes from an attribute on the socket-binding-group element. The XML parser tracks the value and then adds it to the operation to create a socket-binding if the <socket-binding> element doesn't declare an interface. This parser-based approach isn't sufficient as it only works for the parsing use case. Applying it elsewhere forces operations on child model resources (socket-bindings) to find out information stored in parent resources, which we want to avoid. Better IMO is to make the "interface" field on the model representation of a socket binding nullable; the parser should just pass through what the XML says. The SocketBindingManagerService should store the default interface, like it currently stores the port offset. SocketBinding.getAddress() can then ask for the default address from SocketBindingManagerService if its own networkInterface field is null. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8826) No way to apply a socket binding port offset to a standalone server

by Brian Stansberry (JIRA)

No way to apply a socket binding port offset to a standalone server ------------------------------------------------------------------- Key: JBAS-8826 URL: https://issues.jboss.org/browse/JBAS-8826 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Domain Management Affects Versions: 7.0.0.Alpha1 Reporter: Brian Stansberry Assignee: Emanuel Muckenhuber Fix For: 7.0.0.Beta1 There is no place to store the SocketBindingManagerService's port-offset in standalone.xml. Currently it gets passed in as a special value by the HostController, which only works in the domain mode use case. I think the most intuitive thing to do is to add a port-offset attribute to standalone-socket-binding-groupType. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-8801) Undeployment leaks root deployment service

by Thomas Diesler (JIRA)

Undeployment leaks root deployment service ------------------------------------------ Key: JBAS-8801 URL: https://issues.jboss.org/browse/JBAS-8801 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Thomas Diesler To reproduce #1 do a hot-deploy #2 do a hot-undeploy #3 use jconsole to check the installed services. you should see jboss.deployment.yourdeployment As a result redeploy fails with Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:69) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:85) ... 4 more Caused by: java.io.IOException: Filsystem already mounted at mount point ""/content/example-simple.jar"" at org.jboss.vfs.VFS.mount(VFS.java:159) at org.jboss.vfs.VFS.doMount(VFS.java:379) at org.jboss.vfs.VFS.mountZip(VFS.java:405) at org.jboss.as.server.deployment.impl.ServerDeploymentRepositoryImpl.mountDeploymentContent(ServerDeploymentRepositoryImpl.java:78) at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:65) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-8513) Managed bean @Resource injection is premature

by Brian Stansberry (JIRA)

Managed bean @Resource injection is premature --------------------------------------------- Key: JBAS-8513 URL: https://jira.jboss.org/browse/JBAS-8513 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Reporter: Brian Stansberry Fix For: 7.0.0.M1 The way this works now, for a given managed bean type T, the ManagedBeanService<T> would have an instance of each @Resource bean injected as part of start(). Thereafter whenever ManagedBeanContainer.createInstance() is invoked, the same bean instance would be injected into the newly created bean. AIUI what should happen is createInstance() should result in a new naming lookup for each @Resource bean, which in turn would trigger creation of a new instance of that bean. This also causes classloading problems, since doing the injection during the MSC StartTask results in the ManagedBeanObjectFactory not being visible. See forum thread for effect of this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-8432) Clean up stale/unused XSD and XML files

by David Lloyd (JIRA)

Clean up stale/unused XSD and XML files --------------------------------------- Key: JBAS-8432 URL: https://jira.jboss.org/browse/JBAS-8432 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: David Lloyd Fix For: 7.0.0.M1 There are files whose validity is suspect. Don't worry about needing it later; the revisioning system will remember it forever! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011