[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
16 years, 5 months
[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
16 years, 5 months
[JBoss JIRA] Created: (JBMICROCONT-185) Deployment tests need completing
by Adrian Brock (JIRA)
Deployment tests need completing
--------------------------------
Key: JBMICROCONT-185
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-185
Project: JBoss MicroContainer
Issue Type: Task
Components: Deployment
Reporter: Adrian Brock
Fix For: JBossMC_2_0_0_CR1
There are a number of TODOs in the deployer tests.
Additionally, some areas could do with some more testing.
Existing TODOs listed here, but really need subtasks
MockEAR tests
// TODO: need to scan for annotationss
if (scan)
{
throw new RuntimeException("Scanning not implemented: "+file.getName());
}
EARStructure test - this looks broken to me?
public void testNotAnEAR() throws Throwable
{
// TODO ??? This gets recognised by the jar deployer assertNotValid("/structure/ear", "notanear");
}
HACK to make tests work with Maven? - AbstractStructureTest
protected VirtualFile getVirtualFile(String root, String path) throws Exception
{
// TODO THIS IS HACK TO MAKE THE TEST WORK IN MAVEN ???
try
{
URL.setURLStreamHandlerFactory(new URLStreamHandlerFactory()
{
public URLStreamHandler createURLStreamHandler(String protocol)
{
if ("vfsfile".equals(protocol))
return new Handler();
return null;
}
});
}
catch (Error ignored)
{
}
URL url = getResource(root);
Field field = URL.class.getDeclaredField("factory");
field.setAccessible(true);
return VFS.getVirtualFile(url, path);
}
VFSStructureBuilderTest - needs proper testing that the correct classpath was obtained
protected void checkClassPath(VFSDeploymentContext context, ContextInfo contextInfo) throws Exception
{
List<ClassPathEntry> classPathEntries = contextInfo.getClassPath();
List<VirtualFile> classPath = context.getClassPath();
if (classPathEntries == null)
assertNull(classPath);
else
{
// TODO test it got the correct classpath
}
}
--
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, 5 months
[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
16 years, 5 months
[JBoss JIRA] Created: (JBAS-4872) Invalid URI if the jboss.bind.address is IPv6
by Takayoshi Kimura (JIRA)
Invalid URI if the jboss.bind.address is IPv6
---------------------------------------------
Key: JBAS-4872
URL: http://jira.jboss.com/jira/browse/JBAS-4872
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Remoting
Affects Versions: JBossAS-4.2.1.GA
Reporter: Takayoshi Kimura
Assigned To: Ron Sigal
JBossRemoting uses jboss.bind.address in URI like the following:
socket://${jboss.bind.address}:4446/?datatype=invocation
However, if the jboss.bind.address is IPv6, it should be inside
of square brackets.
Invalid URI
socket://::1:4446/?datatype=invocation
Valid URI
socket://[::1]:4446/?datatype=invocation
To reproduce this issue:
Run JBoss instance by the following commend on IPv6 enabled system.
$ ./run.sh -c default -b ::1
Workaround:
Edit JBossRemoting URL not to use jboss.bind.address.
Note:
IPv6 address cannot be parsed with JBossRemoting 2.2.1.GA bundled in 4.2.1.GA. IPv6 parsing needs updated version of JBossRemoting.
http://jira.jboss.com/jira/browse/JBREM-645
--
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, 5 months