September 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-5929) Sub Pooling in JBossManagedConnectionPool MemoryLeak for sparse CRI coverage

by Adrian Brock (JIRA)

Sub Pooling in JBossManagedConnectionPool MemoryLeak for sparse CRI coverage ---------------------------------------------------------------------------- Key: JBAS-5929 URL: https://jira.jboss.org/jira/browse/JBAS-5929 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.3.GA, JBossAS-5.0.0.CR1 Reporter: Adrian Brock Assignee: Jesper Pedersen Fix For: JBossAS-5.0.0.GA, JBossAS-4.2.4.GA If you look at this WIKI page, there is a caveat about "sub-pooling" within the JBossManagedConnectionPool http://wiki.jboss.org/wiki/ConfigJCACommon "Unless the ResourceAdapter has <reauthentication-support> using multiple security identities will create subpools for each identity." The way this works is that we hold a map of CRI->SubPool (CRI == ConnectionRequestInfo). If there is sparse coverage of the CRI parameter space, you can end up with lots of subpools which holds references to each CRI (the same issue also applies to pooling by Subject). The sub-pools will be empted by the IdleRemover, but the sub-pools themselves will be retained which could consume a lot a memory or even cause an OutOfMemoryError depending on the use case. Currently the only way to clear these subpools is manually flush() the pool which will remove all the sub-pools and allow them to be re-created as required. -- 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

16 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-6613) service.bat / jbosssvc.exe fail

by Jochen Reinhardt (JIRA)

service.bat / jbosssvc.exe fail ------------------------------- Key: JBAS-6613 URL: https://jira.jboss.org/jira/browse/JBAS-6613 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Docs/Installation and Getting Started Guide, System service Affects Versions: JBossAS-5.0.1.GA, JBossAS-5.0.0.GA Environment: Tested under Windows XP and Windows Server 2003 with JBoss 5.0.1 and JBoss 5.0.0 Reporter: Jochen Reinhardt The batch job service.bat install fails. Removing @echo from the file revealed the problem: jbosssvc.exe reported: Fehler in .EXE. (Error in .exe.) Does it require some kind of runtime environment, like Visual Studio Runtime Environment? Is the file compiled as 32 or 64 bit binary? I could not find any hints, and the README-service.txt does not mention anything. The Installation And Getting Started Guide does not even mention service.bat or jbosssvc.exe. Instead it refers to JavaService for starting JBoss as Windows service. This is very confusing and cost me several hours today... -- 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

16 years, 6 months

3
9
0 / 0

[JBoss JIRA] Created: (JBAS-5302) StatefulHandleImpl is not portable from client A to client B

by Bernd Zeitler (JIRA)

StatefulHandleImpl is not portable from client A to client B ------------------------------------------------------------ Key: JBAS-5302 URL: http://jira.jboss.com/jira/browse/JBAS-5302 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.2.3.GA Reporter: Bernd Zeitler Assigned To: Alexey Loubyansky The StatefulHandleImpl holds the jndiEnv after creation and uses these properties in getEJBObject. Since jndiEnv is not transient, the properties used on client A are passed within the handle to Client B. This can lead to problems when these two clients use different properties (e.g. different host names for the same physical machine or a different implementation of the NamingContextFactory). Example: client A resides on the JBoss server and realizes remote access to the server using localhost within his URL. A handle, created on this client and passed to client B, which resides on another machine, can not be used to get the EBJ object, since even this clients tries to connect to the server using a lookup on localhost. -- 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

16 years, 6 months

3
8
0 / 0

[JBoss JIRA] Created: (JBAS-6602) Log4jService should use the new JDKLevel class when setting log levels

by Dimitris Andreadis (JIRA)

Log4jService should use the new JDKLevel class when setting log levels ---------------------------------------------------------------------- Key: JBAS-6602 URL: https://jira.jboss.org/jira/browse/JBAS-6602 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Reporter: Dimitris Andreadis Assignee: Dimitris Andreadis Fix For: JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1 This is to allow the dynamic setting of log levels through the setLoggerLevel(logger, level) method, that support the new org.jboss.logging.log4j.JDKLevel levels (i.e. SEVER, WARNING, CONFIG, FINE, FINER, FINEST). -- 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

16 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-6444) commons-codec missing from AS distribution

by Stan Silvert (JIRA)

commons-codec missing from AS distribution ------------------------------------------ Key: JBAS-6444 URL: https://jira.jboss.org/jira/browse/JBAS-6444 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-5.0.0.GA Reporter: Stan Silvert In AS5 GA, commons-httpclient was included in commons/lib. However, httpclient depends on commons-codec which was not included. So we need to either add commons-codec or remove httpclient. >From this discussion, it appears that we should remove httpclient: http://lists.jboss.org/pipermail/jboss-development/2009-January/013397.html The current problem is that the RichFaces demo has: <jboss-web> <class-loading> <loader-repository> org.richfaces.samples.richfaces-demo:loader=richfaces-demo-jee5.war <loader-repository-config>java2ParentDelegation=true</loader-repository-config> </loader-repository> </class-loading> </jboss-web> When you run the demo with JSFUnit, the WAR includes commons-httpclient and commons-codec in WEB-INF/lib. Since parent delegation is true it will use commons-httpclient from commons/lib and then fail because it can't find commons-codec. -- 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

16 years, 6 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-6448) Removing stale JARDeployer

by Thomas Diesler (JIRA)

Removing stale JARDeployer -------------------------- Key: JBAS-6448 URL: https://jira.jboss.org/jira/browse/JBAS-6448 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Build System Reporter: Thomas Diesler Assignee: Paul Gier Fix For: JBossAS-5.0.1.GA The server conf contains xmbean descriptors, some of which are stale AttributePersistenceService-xmbean.xml ClientUserTransaction-xmbean.xml JNDIView-xmbean.xml Log4jService-xmbean.xml NamingBean-xmbean.xml NamingService-xmbean.xml org.jboss.deployment.JARDeployer-xmbean.xml org.jboss.deployment.MainDeployer-xmbean.xml org.jboss.deployment.SARDeployer-xmbean.xml It seems that (at least) JAR/SARDeployer are not used any more. Would it be appropriate to remove them from the code base as well? -- 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

16 years, 6 months

3
7
0 / 0

[JBoss JIRA] Created: (JBAS-6475) Update to JDK LogBridge 1.0.0.GA

by Jason T. Greene (JIRA)

Update to JDK LogBridge 1.0.0.GA -------------------------------- Key: JBAS-6475 URL: https://jira.jboss.org/jira/browse/JBAS-6475 Project: JBoss Application Server Issue Type: Component Upgrade Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assignee: David Lloyd -- 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

16 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (JBAS-6361) log write to server.log does not append to the file as expected

by Calin Medianu (JIRA)

log write to server.log does not append to the file as expected --------------------------------------------------------------- Key: JBAS-6361 URL: https://jira.jboss.org/jira/browse/JBAS-6361 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.GA Environment: Linux 2.6 intel, java 1.6 Reporter: Calin Medianu When I truncate the server.log file (in my case jboss/server/default/log/server.log) the server continues to write at the old offset. This is most likely because the file is not open in append mode. The expected behaviour in unix is that when a file is truncated, using the command: > server.log for instance, the file size is reduced to zero. What happens with jboss is that a file with a hole is created: [jboss@tm03 ~]$ ls -l jboss/server/default/log/server.log -rw-rw-r-- 1 jboss jboss 1840433 Jan 5 01:08 jboss/server/default/log/server.log # I truncate the file [jboss@tm03 ~]$ > jboss/server/default/log/server.log [jboss@tm03 ~]$ ls -l jboss/server/default/log/server.log -rw-rw-r-- 1 jboss jboss 0 Jan 5 01:09 jboss/server/default/log/server.log # the file is size 0 as expected [jboss@tm03 ~]$ ls -l jboss/server/default/log/server.log -rw-rw-r-- 1 jboss jboss 1841656 Jan 5 01:10 jboss/server/default/log/server.log [jboss@tm03 ~]$ ls -s jboss/server/default/log/server.log 12 jboss/server/default/log/server.log # The file has jumped to the reported size of 1841656 but actual size of 12 when the logwriter wrote 12 bytes, but at the old offset of 1840433 This makes it impossible to truncate logs while the server is running. -- 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

16 years, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-6367) missing org.codehaus.plexus:plexus-utils:jar:1.5.6

by Dimitris Andreadis (JIRA)

missing org.codehaus.plexus:plexus-utils:jar:1.5.6 -------------------------------------------------- Key: JBAS-6367 URL: https://jira.jboss.org/jira/browse/JBAS-6367 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Build System Reporter: Dimitris Andreadis Assignee: Paul Gier Fix For: JBossAS-5.1.0.Beta1, JBossAS-6.0.0.Alpha1 When building Branch_5_x & trunk without using external repos, I'm getting: [java] Downloading: http://repository.jboss.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6... [java] [INFO] ------------------------------------------------------------------------ [java] [ERROR] BUILD ERROR [java] [INFO] ------------------------------------------------------------------------ [java] [INFO] Failed to resolve artifact. [java] [java] Missing: [java] ---------- [java] 1) org.codehaus.plexus:plexus-utils:jar:1.5.6 [java] [java] Try downloading the file manually from the project website. [java] [java] Then, install it using the command: [java] mvn install:install-file -DgroupId=org.codehaus.plexus -DartifactId=plexus-utils -Dversion=1.5.6 -Dpackaging=jar -Dfile=/path/to/file [java] [java] Alternatively, if you host your own repository you can deploy the file there: [java] mvn deploy:deploy-file -DgroupId=org.codehaus.plexus -DartifactId=plexus-utils -Dversion=1.5.6 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] [java] [java] Path to dependency: [java] 1) org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.3 [java] 2) org.codehaus.plexus:plexus-utils:jar:1.5.6 [java] [java] ---------- [java] 1 required artifact is missing. [java] [java] for artifact: [java] org.apache.maven.plugins:maven-antrun-plugin:maven-plugin:1.3 [java] [java] from the specified remote repositories: [java] jboss-repository-mirror (http://repository.jboss.org/maven2) [java] [java] -- 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

16 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-6420) JBossWebRealm->hasUserDataPermission check with JBoss Security needs Subject

by Anil Saldhana (JIRA)

JBossWebRealm->hasUserDataPermission check with JBoss Security needs Subject ---------------------------------------------------------------------------- Key: JBAS-6420 URL: https://jira.jboss.org/jira/browse/JBAS-6420 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security, Web (Tomcat) service Affects Versions: JBossAS-5.0.0.GA Reporter: Anil Saldhana Assignee: Anil Saldhana Fix For: JBossAS-5.0.1.GA Tomcat uses the hasUserDataPermission check to see if there is a need for https port redirect. A subject is expected by the JBoss Security layer. Even though the subject does not play any role in the check, it is needed for any authorization. Handle the null subject use case. -- 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

16 years, 6 months

2
4
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 September 2009