[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: (JBXB-205) element name shouldn't be assigned to schemaLocation if namespace is not null
by Alexey Loubyansky (JIRA)
element name shouldn't be assigned to schemaLocation if namespace is not null
-----------------------------------------------------------------------------
Key: JBXB-205
URL: https://jira.jboss.org/jira/browse/JBXB-205
Project: JBoss XML Binding (JBossXB)
Issue Type: Bug
Affects Versions: JBossXB-2.0.1.GA
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: JBossXB-2.0.2.GA
In SundayContentHandler before schema resolution if schemaLocation was not provided in XML and DTD systemId is not available, schemaLocation is assigned to the localName of the element. This is useful for XML files that are validated against DTDs (or don't use a specific namespace). But if the namespace is not null there comes a problem since non-null schema location will override the one used in JBossEntityResolver (making mapping of nsURI to schemaLocation in the resolver useless).
So, assigning schemaLocation to localName should be done only for schemas that don't use namespaces.
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBAS-6758) AS 5 Plugin: Entering Global JNDI name for new ConnectionFactory results in FileNotFoundException
by Shelly McGowan (JIRA)
AS 5 Plugin: Entering Global JNDI name for new ConnectionFactory results in FileNotFoundException
--------------------------------------------------------------------------------------------------
Key: JBAS-6758
URL: https://jira.jboss.org/jira/browse/JBAS-6758
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Shelly McGowan
Fix For: JBossAS-5.1.0.CR1
When entering a Global JNDI name using
eis/ejb_Deployment, an attempt to create the new resource results in the following Exception. Using ejb_Deployment only is successful.
Failed to add Resource (see app server log for additional details): java.lang.RuntimeException:Failed to process template. -> java.lang.RuntimeException:java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment-ds.xml (No such file or directory) -> java.io.FileNotFoundException:/TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment-ds.xml (No such file or directory)
Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment_whitebox-tx.rar-ds.xml (No such file or directory)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.transferDeployment(StreamingDeploymentTarget.java:287)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.distribute(StreamingDeploymentTarget.java:107)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.distribute(DeploymentProgressImpl.java:177)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:82)
at org.jboss.profileservice.management.AbstractTemplateCreator.distribute(AbstractTemplateCreator.java:158)
at org.jboss.profileservice.management.AbstractTemplateCreator.applyTemplate(AbstractTemplateCreator.java:99)
at org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:1005)
<snip>
Caused by: java.io.FileNotFoundException: /TEST/Branch_5_x/build/output/jboss-5.1.0.CR1/server/all/deploy/eis/ejb_Deployment_whitebox-tx.rar-ds.xml (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:179)
at java.io.FileOutputStream.<init>(FileOutputStream.java:131)
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.addDeploymentContent(BasicDeploymentRepository.java:147)
--
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
14 years, 11 months
[JBoss JIRA] Created: (JBAS-6981) AttachmentStore MC bean (org.jboss.system.server.profileservice.repository.AbstractAttachmentStore) configuration does not specify the parameter type for constructor
by jaikiran pai (JIRA)
AttachmentStore MC bean (org.jboss.system.server.profileservice.repository.AbstractAttachmentStore) configuration does not specify the parameter type for constructor
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBAS-6981
URL: https://jira.jboss.org/jira/browse/JBAS-6981
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ProfileService
Affects Versions: JBossAS-5.1.0.GA
Reporter: jaikiran pai
Assignee: Scott M Stark
The profile.xml has this configuration for AttachmentStore:
<bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
<constructor><parameter><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor>
....
However, there are multiple constructors available for org.jboss.system.server.profileservice.repository.AbstractAttachmentStore. MC randomly picks up one of the available constructors and this can lead to exceptions as noted in the referenced forum thread.
The fix is to provide the parameter type for the constructor in the MC bean configuration (note the use of class="java,io.File" for the constructor parameter):
<bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
<constructor><parameter class="java.io.File"><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor>
--
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
14 years, 11 months
[JBoss JIRA] Created: (JGRP-947) Messages that are bundled but are over max_bundle_size are silently dropped on the floor.
by Hunter Kelly (JIRA)
Messages that are bundled but are over max_bundle_size are silently dropped on the floor.
-----------------------------------------------------------------------------------------
Key: JGRP-947
URL: https://jira.jboss.org/jira/browse/JGRP-947
Project: JGroups
Issue Type: Bug
Affects Versions: 2.7
Environment: JGroups version 2.7.0
Reporter: Hunter Kelly
Assignee: Bela Ban
in TP.java, at line 1562, an error is thrown if a packet is too big. However, this exception is caught in TP.java at line 913. It is logged, but in my opinion this error should be propagated all the way up the call stack.
This causes particularly confusing behavior when NACKACK is in the stack, because the next time a message that is sent that is small enough, any and all receivers will ask for a re-transmit of this message from the sender, and the default code path will then _not_ go through the bundler, so the packet will then be successfully sent.
This means that you get a dire looking log message but code that still works, but (potentially) much more inefficiantly.
IMHO, errors like this should be propagated back up to the offending code, so that the error can be detected and corrected.
It also makes it virtually impossible to write test code that tests behaviour of different JGroups configurations.
--
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
14 years, 11 months