January 2008 - jboss-jira - Jboss List Archives

[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

18 years

4
11
0 / 0

[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

18 years

2
8
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

18 years

3
6
0 / 0

[JBoss JIRA] Created: (JBXB-106) xsd:attribute ref not supported by SchemaBinding

by Anil Saldhana (JIRA)

xsd:attribute ref not supported by SchemaBinding ------------------------------------------------ Key: JBXB-106 URL: http://jira.jboss.com/jira/browse/JBXB-106 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-2.0.0.CR2 Reporter: Anil Saldhana Priority: Critical Refer to forum for additional details. -- 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

2
1
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

18 years

2
1
0 / 0

[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

18 years

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4669) Port ClusteredSingleSignOn testNoAuthSingleSignOn test to trunk

by Brian Stansberry (JIRA)

Port ClusteredSingleSignOn testNoAuthSingleSignOn test to trunk --------------------------------------------------------------- Key: JBAS-4669 URL: http://jira.jboss.com/jira/browse/JBAS-4669 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.CR1 Port from Branch_4_2. -- 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

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4616) NamingContext lookupLink() does not acquire stub to server Naming service

by Brian Stansberry (JIRA)

NamingContext lookupLink() does not acquire stub to server Naming service ------------------------------------------------------------------------- Key: JBAS-4616 URL: http://jira.jboss.com/jira/browse/JBAS-4616 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Naming Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta3 org.jnp.interfaces.NamingContext.lookupLink(Name) does not invoke the checkRef() method before invoking on the stub to the server-side Naming object. The checkRef() method is what actually contacts the JNDI server to download the stub.. Result of this is an NPE will be thrown if an earlier call hasn't downloaded the stub before lookupLink() is called. -- 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

1
8
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1832) -object.xml files should be orderable

by Sylvain FRANCOIS (JIRA)

-object.xml files should be orderable ------------------------------------- Key: JBPORTAL-1832 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1832 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.2 Final Reporter: Sylvain FRANCOIS -object.xml files are loaded without any order rule. This makes mangement of portal/page definitions very difficult with "overwrite" mode since you can't assume if parent has already been loaded or not. It should be easy to fix this (I've made a temporary patch) : descriptors URL are already sorted before parsing, but their parsing results are put in a non-sorted Map (cf. org.jboss.portal.server.deployment.jboss.PortalDeploymentInfoContext). PS : my -object.xml files follow this structure (all with 'overwrite' mode) : portal-object.xml toppage-x-object.xml (with all its subpages) toppage-y-object.xml (with all its subpages) toppage-z-object.xml (with all its subpages) ... -- 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

5
19
0 / 0

[JBoss JIRA] Created: (JBWEB-87) JasperException for JSP page using generics

by David Ward (JIRA)

JasperException for JSP page using generics ------------------------------------------- Key: JBWEB-87 URL: http://jira.jboss.com/jira/browse/JBWEB-87 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Environment: Customer submitted using AS 4.2.0.GA and Sun JDK 1.5.0_11. I verified using AS 4.2.0.GA and AS 4.2.1.GA and Sun JDK 1.6.0_02. Reporter: David Ward Assigned To: Mladen Turk I am submitting this as a JBoss Web bug; not sure if it should have been submitted as an AS bug instead... This test.jsp page does not compile in AS 4.2.0 or AS 4.2.1: <%@page contentType="text/html" import="java.util.*" %> <html><head><title>test</title></head><body> <% Vector<String> v = (Vector<String>)request.getSession().getAttribute("v"); out.println("v: " + v); %> </body></html> However, it does with a workaround (please see "Workaround Description" below). I believe that this is a bug since we require a 1.5 JVM for AS 4.2.x. Here is the error without using the workaround: 15:41:21,960 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception org.apache.jasper.JasperException: Unable to compile class for JSP: An error occurred at line: 4 in the jsp file: /test.jsp The type Vector is not generic; it cannot be parameterized with arguments <String> 1: <%@page contentType="text/html" import="java.util.*" %> 2: <html><head><title>test</title></head><body> 3: <% 4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v"); 5: out.println("v: " + v); 6: %> 7: </body></html> An error occurred at line: 4 in the jsp file: /test.jsp Syntax error, parameterized types are only available if source level is 5.0 1: <%@page contentType="text/html" import="java.util.*" %> 2: <html><head><title>test</title></head><body> 3: <% 4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v"); 5: out.println("v: " + v); 6: %> 7: </body></html> An error occurred at line: 4 in the jsp file: /test.jsp The type Vector is not generic; it cannot be parameterized with arguments <String> 1: <%@page contentType="text/html" import="java.util.*" %> 2: <html><head><title>test</title></head><body> 3: <% 4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v"); 5: out.println("v: " + v); 6: %> 7: </body></html> An error occurred at line: 4 in the jsp file: /test.jsp Syntax error, parameterized types are only available if source level is 5.0 1: <%@page contentType="text/html" import="java.util.*" %> 2: <html><head><title>test</title></head><body> 3: <% 4: Vector<String> v = (Vector<String>)request.getSession().getAttribute("v"); 5: out.println("v: " + v); 6: %> 7: </body></html> Stacktrace: at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92) at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330) at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:415) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:308) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:286) at org.apache.jasper.compiler.Compiler.compile(Compiler.java:273) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:566) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) -- 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

2
1
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 January 2008