October 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3775) org.jboss.net.protocol.file.FileURLConnection does not handle opening InputStreams to UNC paths properly

by David Kilzer (JIRA)

org.jboss.net.protocol.file.FileURLConnection does not handle opening InputStreams to UNC paths properly -------------------------------------------------------------------------------------------------------- Key: JBAS-3775 URL: http://jira.jboss.com/jira/browse/JBAS-3775 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.0.2 Final Environment: Microsoft Windows XP [Version 5.1.2600] java version "1.5.0_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode) Xerces-J 2.6.2 Reporter: David Kilzer Attempting to parse a document using Xerces-J 2.6.2 by passing in a java.io.File object containing a UNC path fails when run under JBossAS 4.0.2 Final, but works fine when run outside of JBoss. The particular code run under JBoss was started through a Spring-1.2.8-controlled Quartz-1.4.5 job (all deployed within a WAR within an EAR), but the stack trace clearly shows that org.jboss.net.protocol.file.FileURLConnection is the culprit (file path changed to protect the innocent): java.io.FileNotFoundException: \c$\path\to\file.xml at org.jboss.net.protocol.file.FileURLConnection.connect(FileURLConnection.java:80) at org.jboss.net.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:89) at java.net.URL.openStream(URL.java:1007) at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source) at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:172) [...] Here is some sample code that should reproduce the issue. Note the path used to create the java.io.File object. File xmlFile = new File("\\\\127.0.0.1\\c$\\path\\to\\file.xml"): DocumentBuilderFactory factory = new org.apache.xerces.jaxp.DocumentBuilderFactoryImpl(); factory.setNamespaceAware(false); factory.setValidating(false); DocumentBuilder builder = factory.newDocumentBuilder(); Document document = builder.parse(xmlFile); // exception thrown under JBossAS The FileURLConnection class is loaded from jboss-4.0.2/client/jboss-common-client.jar. -- 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

15 years, 12 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-983) Upload of large files fails.

by Peter Johnson (JIRA)

Upload of large files fails. ---------------------------- Key: JBPORTAL-983 URL: http://jira.jboss.com/jira/browse/JBPORTAL-983 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4 Final Environment: Windows XP, JDK 1.5, JBoss AS 4.0.4GA Reporter: Peter Johnson Fix For: 2.4 Final Using the CMS Admin portlet, I attempted to upload a zip file into a directory, as per section 3.2.9 of the User Guide. Initially I tried a zip ofabout 6MB containing many files, and eventually got down to a a zip file of about 500M with only a single Word document inside. The upload failed and an "SQLException: could not reset reader" error appeared (see forum post for stack trace). I am, however, able to upload very small zip files. -- 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

15 years, 12 months

8
23
0 / 0

[JBoss JIRA] Created: (JBAS-3402) Web Console and Firefox

by Vladimir Gendler (JIRA)

Web Console and Firefox ----------------------- Key: JBAS-3402 URL: http://jira.jboss.com/jira/browse/JBAS-3402 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Management services Affects Versions: JBossAS-4.0.4.GA Environment: MS W2000 SP4 Reporter: Vladimir Gendler Assigned To: Dimitris Andreadis Web Console output in Mozilla Firefox (and Seamonkey) is messed up. Compare the attached archive with snapshots from Mozilla Firefox and MSIE. -- 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

4
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-746) Ascertain whether any methods and attributes exposed by TreeCacheMBean can be marked serializable

by Jerry Gauthier (JIRA)

Ascertain whether any methods and attributes exposed by TreeCacheMBean can be marked serializable ------------------------------------------------------------------------------------------------- Key: JBCACHE-746 URL: http://jira.jboss.com/jira/browse/JBCACHE-746 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jerry Gauthier Assigned To: Jerry Gauthier Priority: Minor When TreeCacheMBean is accessed remotely via an mbean server such as jconsole, numerous attributes and methods are marked as problematic because they aren't serializable. While many are undoubtedly not serializable, it's worth reviewing the list to see if it would be appropriate to mark any additional attributes or method parameters as serializable. -- 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

3
4
0 / 0

[JBoss JIRA] Created: (JBREM-577) Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol

by Ron Sigal (JIRA)

Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol ---------------------------------------------------------------------------------------------------------------------- Key: JBREM-577 URL: http://jira.jboss.com/jira/browse/JBREM-577 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA (Boon) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.0.0.GA (Boon) This test is failing rather consistently in testRule4ServerFirst() on cruisecontrol, even though this particular failure can't be reproduced on any other environment. In case the problem is more than environmental, i.e., a real problem in Multiplex, some additional log statements will be added to MultiplexServerInvoker and OutputMultiplexor. What is happening is that in runPushCallbackTests(), the message "stopped callback Connector" appears, but then the test dies before the callback Connector completes its shut down. It would be nice to believe that there is a deadlock, but none is evident, unless it's due to a problem with Collections.synchronizedMap in jdk 1.4. Note that this problem never occurs in the jdk 1.5 cruisecontrol tests. -- 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

3
10
0 / 0

[JBoss JIRA] Created: (JBREM-549) remove dependancy on concurrent.jar within remoting client

by Tom Elrod (JIRA)

remove dependancy on concurrent.jar within remoting client ---------------------------------------------------------- Key: JBREM-549 URL: http://jira.jboss.com/jira/browse/JBREM-549 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.Beta2 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.CR1 (Boon) Currently, the remoting clients will require concurrent.jar to be on the classpath because org.jboss.util.id.GUID is used to create the client session id. Problem is that org.jboss.util.id.GUID is what requires concurrent.jar. So will either need to modify the code within jboss common repository or find another class to use for generating the client session id. java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/SynchronizedLong at org.jboss.util.id.UID.<clinit>(UID.java:56) at org.jboss.util.id.VMID.create(VMID.java:259) at org.jboss.util.id.VMID.getInstance(VMID.java:223) at org.jboss.util.id.GUID.<init>(GUID.java:65) at org.jboss.remoting.Client.<init>(Client.java:133) at org.jboss.remoting.Client.<init>(Client.java:210) at org.jboss.remoting.Client.<init>(Client.java:191) at org.jboss.test.remoting.transport.InvokerClientTest.init(InvokerClientTest.java:80) -- 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

3
12
0 / 0

[JBoss JIRA] Created: (JBREM-554) Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool.

by Ron Sigal (JIRA)

Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool. -------------------------------------------------------------------------------------- Key: JBREM-554 URL: http://jira.jboss.com/jira/browse/JBREM-554 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta1 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta1 (Bluto) This is JBREM-402, broken out from JBREM-390. -- 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

3
8
0 / 0

[JBoss JIRA] Created: (JBREM-599) remoting doc does not cover enabling or configuring leasing from the client side

by Tom Elrod (JIRA)

remoting doc does not cover enabling or configuring leasing from the client side -------------------------------------------------------------------------------- Key: JBREM-599 URL: http://jira.jboss.com/jira/browse/JBREM-599 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: docs Affects Versions: 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Priority: Minor Fix For: 2.2.0.Beta1 (Bluto) -- 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

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-3707) HA/Failover RAR Functionality should be implemented in non-HA RARS.

by Weston Price (JIRA)

HA/Failover RAR Functionality should be implemented in non-HA RARS. ------------------------------------------------------------------- Key: JBAS-3707 URL: http://jira.jboss.com/jira/browse/JBAS-3707 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.6.CR1 Reporter: Weston Price Assigned To: Weston Price Priority: Optional The HA/DB failover functionality for JDBC RARs currently exists in seperated deployments (ha/xa rars). This functionality should be put into the regular RARs as a deployment option and not as a standalone configuration which is unnecessary. -- 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, 1 month

4
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-698) Exception serialization issue when remotely accessing stateless session bean

by David Green (JIRA)

Exception serialization issue when remotely accessing stateless session bean ---------------------------------------------------------------------------- Key: EJBTHREE-698 URL: http://jira.jboss.com/jira/browse/EJBTHREE-698 Project: EJB 3.0 Issue Type: Bug Reporter: David Green Accessing a remote EJB (Session bean) results in exception. Stack trace follows: 13:54:39,546 ERROR [SocketClientInvoker] Got marshalling exception, exiting java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement; at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50) at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496) at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) at $Proxy0.postNotification(Unknown Source) at com.hgea.hch.service.HchClientDelegate.postNotification(HchClientDelegate.java:99) at com.hgea.hch.client.RemoteHchClientTest.testRemotePostNotification(RemoteHchClientTest.java:38) 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:597) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) -- 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, 1 month

7
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2006