[JBoss JIRA] Created: (JBAS-4012) ClassLoaderUtils recurses into .war directories
by David (JIRA)
ClassLoaderUtils recurses into .war directories
-----------------------------------------------
Key: JBAS-4012
URL: http://jira.jboss.com/jira/browse/JBAS-4012
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-4.0.5.GA
Environment: windows xp, java 1.5.0_09
Reporter: David
Assigned To: Scott M Stark
Priority: Minor
ClassLoaderUtils has logic that is supposed to prevent indexing/scanning of .war directories. This was an issue fixed earlier in 3.2.6, reported in a support case: 00002351
The following patch is also needed in order to fully prevent indexing in .war directories:
$ diff -u src/org/jboss/mx/loading/ClassLoaderUtils.java /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java
--- src/org/jboss/mx/loading/ClassLoaderUtils.java 2007-01-24 14:27:27.607071000 -0500
+++ /khub/opensource/jboss-4.0.5.GA-src/jmx/src/main/org/jboss/mx/loading/ClassLoaderUtils.java 2006-10-16 23:37:24.000000000 -0400
@@ -472,27 +472,21 @@
String name = start.getName();
// Don't recurse into wars
boolean isWar = name.endsWith(".war");
- if( isWar ) {
- log.trace("war, not recursing");
+ if( isWar )
currentListing = new File[0];
- }
- else {
+ else
currentListing = start.listFiles();
- }
}
FileIterator(File start, FileFilter filter)
{
String name = start.getName();
// Don't recurse into wars
boolean isWar = name.endsWith(".war");
- if( isWar ) {
- log.trace("war, not recursing");
+ if( isWar )
currentListing = new File[0];
- }
- else {
+ else
currentListing = start.listFiles(filter);
- this.filter = filter;
- }
+ this.filter = filter;
}
File getNextEntry()
@@ -503,13 +497,7 @@
do
{
File nextDir = (File) subDirectories.removeFirst();
- if (nextDir.getName().endsWith(".war")) {
- log.trace("war, not recursing");
- currentListing = new File[0];
- }
- else {
- currentListing = nextDir.listFiles(filter);
- }
+ currentListing = nextDir.listFiles(filter);
} while( currentListing.length == 0 && subDirectories.size() > 0 );
index = 0;
}
The stack trace during startup is here:
"main" prio=6 tid=0x1bcadc70 nid=0xec4 runnable [0x1c02e000..0x1c02fb18]
at java.io.WinNTFileSystem.list(Native Method)
at java.io.File.list(File.java:937)
at java.io.File.listFiles(File.java:1093)
at org.jboss.mx.loading.ClassLoaderUtils$FileIterator.getNextEntry(ClassLoaderUtils.java:500)
at org.jboss.mx.loading.ClassLoaderUtils$ClassPathIterator.getNextEntry(ClassLoaderUtils.java:617)
at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:319)
at org.jboss.mx.loading.ClassLoaderUtils.updatePackageMap(ClassLoaderUtils.java:253)
at org.jboss.mx.loading.UnifiedLoaderRepository3.updatePackageMap(UnifiedLoaderRepository3.java:783)
at org.jboss.mx.loading.UnifiedLoaderRepository3.addRepositoryClassLoader(UnifiedLoaderRepository3.java:740)
- locked <0x07aafcf0> (a EDU.oswego.cs.dl.util.concurrent.CopyOnWriteArraySet)
at org.jboss.mx.loading.UnifiedLoaderRepository3.addClassLoader(UnifiedLoaderRepository3.java:662)
at org.jboss.mx.loading.UnifiedLoaderRepository3.registerClassLoader(UnifiedLoaderRepository3.java:946)
at org.jboss.mx.loading.UnifiedLoaderRepository3.newClassLoader(UnifiedLoaderRepository3.java:168)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.deployment.DeploymentInfo.createClassLoaders(DeploymentInfo.java:280)
at org.jboss.deployment.MainDeployer.init(MainDeployer.java:874)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:809)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
- locked <0x07e0e0d8> (a org.jboss.deployment.scanner.URLDeploymentScanner)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
- locked <0x07ec9400> (a org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
- locked <0x07af6660> (a org.jboss.system.ServiceController)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:490)
at java.lang.Thread.run(Thread.java:595)
with trace logging on you see:
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBAS-3834) i18n of jmx-console
by Ryusuke Kajiyama (JIRA)
i18n of jmx-console
-------------------
Key: JBAS-3834
URL: http://jira.jboss.com/jira/browse/JBAS-3834
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-4.0.4.GA
Environment: Any operating system with multiple language such as MS932 (Japanese)
Reporter: Ryusuke Kajiyama
We found that there are difference in screen-displayed multibyte characters on using Internet Explorer and Firefox. When using MS932, with IE, characters are returned same as posted, however with Firefox, characters are url-escaped like %xx. Our guess is that html of jmx-console does not have charset and there are no functions to handle encoding request parameter.
It could be fixed if there were some filter action something like distinguish character set of posted data, and add <meta> tag into html or set Content-Type.
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBAS-4154) Get the server to run under a security manager
by Scott M Stark (JIRA)
Get the server to run under a security manager
----------------------------------------------
Key: JBAS-4154
URL: http://jira.jboss.com/jira/browse/JBAS-4154
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.0.0.Beta1
Reporter: Scott M Stark
Assigned To: Scott M Stark
The testsuite tests-security-manager target was failing due to the aop layer not creating classes with correct ProtectionDomains. This is fixed in (JBAOP-368). The next problem is that the server.policy needs to use vfsfile urls for the permission assignments. However, because these are URLs and not URIs, there has to be a URL handler available when the policy is read at bootstrap. Currently a policy entry like:
grant codeBase "vfsfile:${jboss.home.dir}/lib/-" {
permission java.security.AllPermission;
};
fails because the jboss vfsfile URL handler is unknown:
policy: Adding policy entry:
policy: signedBy null
policy: codeBase vfsfile:/tmp/trunk/build/output/jboss-5.0.0.Beta2/lib/-
java.security.policy: error adding Entry:
java.net.MalformedURLException: unknown protocol: vfsfile policy:
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBAS-3765) AOP-based version of RetryInterceptor
by Brian Stansberry (JIRA)
AOP-based version of RetryInterceptor
-------------------------------------
Key: JBAS-3765
URL: http://jira.jboss.com/jira/browse/JBAS-3765
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: EJB2, EJB3, Remoting
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.Beta
The (Single)RetryInterceptor only works for EJB 2. Need to:
1) Create a version that uses the AOP interceptor model rather than org.jboss.invocation.
2) Ensure all proxy factories bind an InvokerLocator in JNDI and include in the proxy metadata the location of the binding.
3) Add the interceptor to the various interceptor stack configs.
--
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
14 years, 12 months