June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMICROCONT-150) VFS callers are missing privileged blocks

by Scott M Stark (JIRA)

VFS callers are missing privileged blocks ----------------------------------------- Key: JBMICROCONT-150 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-150 Project: JBoss MicroContainer Issue Type: Sub-task Reporter: Scott M Stark Fix For: JBossMC_2_0_0 Beta3 For the particular failures its the org.jboss.deployers.plugins.structure.vfs.explicit.DeclaredStructure caller that needs to wrap the vfs call in a priviledged block. Not all vfs calls to priviledged ops should be wrapped in priviledged blocks. -- 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

17 years, 11 months

5
10
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-149) VFS is missing privileged blocks

by Scott M Stark (JIRA)

VFS is missing privileged blocks -------------------------------- Key: JBMICROCONT-149 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-149 Project: JBoss MicroContainer Issue Type: Bug Components: VFS Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0 Beta3 Run ant tests-security-manager in jbossas: http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/... 16:35:49,790 DEBUG [MainDeployerImpl] Add deployment context: vfsfile:/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/build/output/jboss-5.0.0.Beta2/server/default/conf/jboss-service.xml 16:35:49,799 WARN [DeclaredStructure] Error determining structure:jboss-service.xml java.security.AccessControlException: access denied (java.io.FilePermission/services/cruisecontrol/checkout/jboss-head-testsuite-sun-1.5/build/output/jboss-5.0.0.Beta2/server/default/conf/jboss-service.xml read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264) at java.security.AccessController.checkPermission(AccessController.java:427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkRead(SecurityManager.java:871) at java.io.File.isFile(File.java:745) at org.jboss.virtual.plugins.context.file.FileHandler.isLeaf(FileHandler.java:133) at org.jboss.virtual.VirtualFile.isLeaf(VirtualFile.java:182) -- 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

17 years, 11 months

4
10
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-157) Leak due to VirtualFileURLConnection.class.urlCache()

by Scott M Stark (JIRA)

Leak due to VirtualFileURLConnection.class.urlCache() ----------------------------------------------------- Key: JBMICROCONT-157 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-157 Project: JBoss MicroContainer Issue Type: Bug Components: VFS Affects Versions: JBossMC_2_0_0 Beta3 Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0_CR1 > I think I got another one. > There is a static ref to the VFS in VirtualFileURLConnection. In the end > the VirtualFile is kept in memory. See left bottom on the picture. If > these are the things to look for, then I got a bundle more. > Note that the VirtualFile is actually a reference to an EJB3 deployment, > so it's probably EJB3 code not cleaning up properly. But this shouldn't > lock down a ref in VFS. There is definately a memory leak in VirtualFileURLConnection.class.urlCache(). It grows without bounds. After an incomplete JBossWS test run 53 megs of heap is tied to this cache. -- 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

17 years, 11 months

4
11
0 / 0

[JBoss JIRA] Created: (JBAS-4071) Provide information about non-XA resource participating in multibranch transactions

by Mauricio Seeberger (JIRA)

Provide information about non-XA resource participating in multibranch transactions ----------------------------------------------------------------------------------- Key: JBAS-4071 URL: http://jira.jboss.com/jira/browse/JBAS-4071 Project: JBoss Application Server Issue Type: Patch Security Level: Public (Everyone can see) Components: Other, Transaction Manager Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA Environment: Linux 2.6.9 RHEL4 on AMD64 and jdk 1.5.0_09-amd64. Reporter: Mauricio Seeberger When you have more than one non-XA resource participating in a multibranch transaction, then you have a problem in your code and sooner or later it will result in inconsistent data. But JBoss (TxConnectionManager) just logs just once a generic message: Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure. We need more information about the resource and a stack trace for identifying the malicious code. -- 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

17 years, 11 months

3
6
0 / 0

[JBoss JIRA] Created: (JBWEB-71) Making Http Request Parameters available to Login Modules via Callbacks

by Sriraman Gopalan (JIRA)

Making Http Request Parameters available to Login Modules via Callbacks ----------------------------------------------------------------------- Key: JBWEB-71 URL: http://jira.jboss.com/jira/browse/JBWEB-71 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tomcat Module Reporter: Sriraman Gopalan Assigned To: Mladen Turk The details of the feature request are given in the forum under the following thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=97420 -- 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

17 years, 12 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWEB-70) Add

by Amit Kasher (JIRA)

Add ---- Key: JBWEB-70 URL: http://jira.jboss.com/jira/browse/JBWEB-70 Project: JBoss Web Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Amit Kasher Assigned To: Mladen Turk -- 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

17 years, 12 months

2
2
0 / 0

[JBoss JIRA] Created: (JBWEB-65) context.xml is ignored.

by Nicolas Leroux (JIRA)

context.xml is ignored. ----------------------- Key: JBWEB-65 URL: http://jira.jboss.com/jira/browse/JBWEB-65 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBoss Web Standalone 4.0.4 RC1 Reporter: Nicolas Leroux Assigned To: Mladen Turk The context.xml file is ignored by jboss. It's thus impossible to setup the docRoot property. I followed the wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingContextDotXML without any success (The context.xml is in my META-INF). -- 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

17 years, 12 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4282) Can't create a root context web app

by Stan Silvert (JIRA)

Can't create a root context web app ----------------------------------- Key: JBAS-4282 URL: http://jira.jboss.com/jira/browse/JBAS-4282 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Stan Silvert Assigned To: Remy Maucherat I am unable to deploy a web app as root context using the instructions here: http://wiki.jboss.org/wiki/Wiki.jsp?page=SetupARootContextApp One thing that is unclear is if ROOT.war "must" be removed from /deploy. In 4.2, root context web apps do not require removal of ROOT.war. IMHO, this is how it should work. If you deploy a WAR as the root context, it should simply override whatever was there before. If ROOT.war is removed, 5.0 will allow a root context web app as long as it is deployed from an EAR and specified as such in application.xml. Otherwise, it will fail. If you choose to deploy a stand-alone WAR and specify it as root context using jboss-web.xml, it will always fail - regardless of whether or not you remove ROOT.war. I have committed a test for root deployment in both 4.2 and 5.0. The test passes in 4.2, but not in 5.0. You can run it with: build one-test -Dtest=org.jboss.test.web.test.RootContextUnitTestCase -- 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

17 years, 12 months

3
3
0 / 0

[JBoss JIRA] Created: (JGRP-494) Investigate marshalling format to simplify wireshark / ethereal plugin

by Bela Ban (JIRA)

Investigate marshalling format to simplify wireshark / ethereal plugin ----------------------------------------------------------------------- Key: JGRP-494 URL: http://jira.jboss.com/jira/browse/JGRP-494 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Currently, parsing JGroups network data via wireshark is difficult: - message lists don't have (a) total number of bytes and (b) bytes/message and - headers don't have (a) total bytes for all headers and (b) bytes / header Investigate whether we can change the marshalling format to accommodate the wireshark plugin. This has the nice side effect that the JGroups wire format becomes standardized, ie. each header has the same format. This allows us to display a header even if we don't know how to parse it. In this case, we'd simply display the name and number of bytes. Caveat: we want to avoid having to make messages bigger when marshalled. -- 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

17 years, 12 months

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-3911) Default max-pool-size in DataSource configuration

by Shrinivas Joshi (JIRA)

Default max-pool-size in DataSource configuration ------------------------------------------------- Key: JBAS-3911 URL: http://jira.jboss.com/jira/browse/JBAS-3911 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.0.5.GA Reporter: Shrinivas Joshi Assigned To: Weston Price In *-[xa]-ds.xml if max-pool-size is not specified and only min-pool-size is specified then max-pool-size should be set = min-pool-size whereas it defaults to 20 rendering min-pool-size setting of no use. -- 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

18 years

6
8
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 June 2007