[JBoss-dev] [ jboss-Bugs-1472788 ] java.lang.NoSuchMethodError: javax.servlet.http.HttpServletR
Bugs item #1472788, was opened at 2006-04-19 12:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1472788&group_id=22866 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: JBossServer Group: v4.0 Status: Open Resolution: None Priority: 5 Submitted By: Nishant Saini (nishantsaini) Assigned to: Nobody/Anonymous (nobody) Summary: java.lang.NoSuchMethodError: javax.servlet.http.HttpServletR Initial Comment: I am using HttpNamingContextFactory for looking up an EJB Home deployed on server. I am using JBoss 4.0.4-RC1 and I get the following error: java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.resetBuffer()V at org.jboss.invocation.http.servlet.InvokerServlet.processRequest(InvokerServlet.java:193) at org.jboss.invocation.http.servlet.InvokerServlet.doGet(InvokerServlet.java:214) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:174) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595) Can you please suggest the solution ? I think there is some incompatible jar from which HttpServletResponse class is being loaded and the method resetBuffer() must have been present at compile time. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=1472788&group_id=22866 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-661682 ] 3.1 dtd missing from XmlFileLoader
Bugs item #661682, was opened at 2003-01-03 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=661682&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Oskari Kettunen (aok) Assigned to: Nobody/Anonymous (nobody) Summary: 3.1 dtd missing from XmlFileLoader Initial Comment: Hello gents, Somewhere along the way of fitting together xdoclet1.2 and jboss3.2 I ran into a stalemate of descriptors ad dtds fixed easiest by adding the 3.1 dtd to XmlFileLoader. I suspect you might have some reason for keeping it out of 3.2, but in case this is just an oversight, attached is a one-line diff. Oskari Kettunen, Krocus Communications OY Finland -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=661682&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-661682 ] 3.1 dtd missing from XmlFileLoader
Bugs item #661682, was opened at 2003-01-03 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=661682&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None >Priority: 6 Submitted By: Oskari Kettunen (aok) Assigned to: Nobody/Anonymous (nobody) Summary: 3.1 dtd missing from XmlFileLoader Initial Comment: Hello gents, Somewhere along the way of fitting together xdoclet1.2 and jboss3.2 I ran into a stalemate of descriptors ad dtds fixed easiest by adding the 3.1 dtd to XmlFileLoader. I suspect you might have some reason for keeping it out of 3.2, but in case this is just an oversight, attached is a one-line diff. Oskari Kettunen, Krocus Communications OY Finland -- >Comment By: Oskari Kettunen (aok) Date: 2003-01-03 17:39 Message: Logged In: YES user_id=558871 this file upload thingy is taking a piss at me... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=661682&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-662098 ] class loader deadlock new for 3.2Beta3
Bugs item #662098, was opened at 2003-01-04 12:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=662098&group_id=22866 Category: None Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Dorothy Gantenbein (dgantenbein) Assigned to: Nobody/Anonymous (nobody) Summary: class loader deadlock new for 3.2Beta3 Initial Comment: Class loader deadlock occurs on Windows XP, Windows 2000 and Linus. Using JDK 1.4.1_01 and JBoss 3.2 Beta3. This was not a problem using JBoss 3.2 Beta1. For us, this deadlock occurs using Cactus' ant task to do automated nightly testing (runservertasks). This ant task starts JBoss, and JBoss freezes during startup at various points. At the bottom of this information is the information about the deadlock from OptimizeIt's thread debugger. The stacktraces to the two threads involved in the deadlock are included (tcpConnection-8080-1 and main). For tcpConnection-8080-1 thread, the resin classes appear in the stacktrace. I have confirmed that the resin classes shown in the stacktrace are NOT holding any monitor on a class. Thread tcpConnection-8080-1 enters monitor java.lang.Class 0xaf35760 first and then org.jboss.mx.loading.UnifiedClassLoader3 0xb124f80 while thread main enters in opposite order. Thread [tcpConnection-8080-1] (Suspended) java.lang.Object.wait(long) line: not available [native method] org.jboss.mx.loading.ClassLoadingTask (java.lang.Object).wait() line: 426 org.jboss.mx.loading.UnifiedClassLoader3.loa dClass(java.lang.String, boolean) line: 175 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClass(java.lang.String) line: 262 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClassInternal (java.lang.String) line: 322 java.lang.ClassLoader.defineClass0 (java.lang.String, byte[], int, int, java.security.ProtectionDomain) line: not available [native method] org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).defineClass(java.lang.String, byte[], int, int, java.security.ProtectionDomain) line: 509 org.jboss.mx.loading.UnifiedClassLoader3 (java.security.SecureClassLoader).defineClass (java.lang.String, byte[], int, int, java.security.CodeSource) line: 123 org.jboss.mx.loading.UnifiedClassLoader3 (java.net.URLClassLoader).defineClass(java.lang.String, sun.misc.Resource) line: 246 java.net.URLClassLoader.access$100 (java.net.URLClassLoader, java.lang.String, sun.misc.Resource) line: 54 java.net.URLClassLoader$1.run() line: 193 java.security.AccessController.doPrivileged (java.security.PrivilegedExceptionAction, java.security.AccessControlContext) line: not available [native method] org.jboss.mx.loading.UnifiedClassLoader3 (java.net.URLClassLoader).findClass(java.lang.String) line: 186 org.jboss.mx.loading.UnifiedClassLoader3 (org.jboss.mx.loading.UnifiedClassLoader).findClass (java.lang.String) line: 444 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClass(java.lang.String, boolean) line: 306 org.jboss.mx.loading.UnifiedClassLoader3 (org.jboss.mx.loading.UnifiedClassLoader).loadClassLoc ally(java.lang.String, boolean) line: 250 org.jboss.mx.loading.UnifiedLoaderRepository 3.loadClassFromClassLoader(java.lang.String, boolean, org.jboss.mx.loading.UnifiedClassLoader) line: 187 org.jboss.mx.loading.LoadMgr.beginLoadTas k(org.jboss.mx.loading.ClassLoadingTask, org.jboss.mx.loading.UnifiedLoaderRepository3) line: 119 org.jboss.mx.loading.UnifiedClassLoader3.loa dClass(java.lang.String, boolean) line: 161 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClass(java.lang.String) line: 262 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClassInternal (java.lang.String) line: 322 com.caucho.jsp.JspParser.parse (com.caucho.vfs.ReadStream, java.lang.String, java.lang.String, java.lang.String, com.caucho.vfs.Path, com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoApplication) line: 282 com.caucho.jsp.JspParser.parse (com.caucho.vfs.ReadStream, com.caucho.vfs.Path, java.lang.String, java.lang.String, java.lang.String, com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoApplication, com.caucho.java.LineMap, boolean, java.util.ArrayList) line: 258 com.caucho.jsp.XtpPage.getJspPage (com.caucho.xml.CauchoDocument, javax.xml.transform.Templates, com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoResponse, java.lang.String) line: 602 com.caucho.jsp.XtpPage.compileJspPage (com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoResponse, com.caucho.xml.CauchoDocument, javax.xml.transform.Templates, java.l
[JBoss-dev] [ jboss-Bugs-644287 ] in a Filter, getServletPath() empty
Bugs item #644287, was opened at 2002-11-26 19:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644287&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: James Manning (jmm) Assigned to: Nobody/Anonymous (nobody) Summary: in a Filter, getServletPath() empty Initial Comment: using the servlet 2.3 API, in a defined filter (extends HttpServlet implements Filter), inside method public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) HttpServletRequest httpServletRequest = (HttpServletRequest)request; String current_file = httpServletRequest.getServletPath(); This works great under Tomcat 4.x but returns an empty string (not null, just empty) in jboss 3.0.4 Trying to put together the minimal webapp to show the bug now. Wanted to go ahead and get the bug posted just in case it's known or something -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-04 13:40 Message: Logged In: YES user_id=44062 Can you attach the source code of your example please. -- Comment By: James Manning (jmm) Date: 2002-11-26 21:09 Message: Logged In: YES user_id=11485 in case it helps, adding another check for getRequestURI shows: (under Tomcat 4.x) 10095 [HttpProcessor[8000][3]] INFO TestFilter - *** getServletPath gives /foo/bar/ack 10095 [HttpProcessor[8000][3]] INFO TestFilter - *** getRequestURI gives /filter/foo/bar/ack under jboss 3.0.4 16:09:28,870 INFO [TestFilter] *** getServletPath gives 16:09:28,870 INFO [TestFilter] *** getRequestURI gives /filter/foo/bar/ack Both are being hit by IE with a url of http://127.0.0.1:8080/filter/foo/bar/ack (port number changed to point to each one) -- Comment By: James Manning (jmm) Date: 2002-11-26 20:13 Message: Logged In: YES user_id=11485 on Tomcat 4.x 0 [HttpProcessor[8000][3]] INFO TestFilter - *** getServletPath gives /foo/bar/ack So this appears (afaict) to be a jboss breakage -- Comment By: James Manning (jmm) Date: 2002-11-26 20:02 Message: Logged In: YES user_id=11485 this is the minimal test-case AFAICT. logging shows: 15:02:14,709 INFO [TestFilter] *** getServletPath gives -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644287&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-644287 ] in a Filter, getServletPath() empty
Bugs item #644287, was opened at 2002-11-26 19:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644287&group_id=22866 Category: JBossWeb Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: James Manning (jmm) Assigned to: Nobody/Anonymous (nobody) Summary: in a Filter, getServletPath() empty Initial Comment: using the servlet 2.3 API, in a defined filter (extends HttpServlet implements Filter), inside method public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) HttpServletRequest httpServletRequest = (HttpServletRequest)request; String current_file = httpServletRequest.getServletPath(); This works great under Tomcat 4.x but returns an empty string (not null, just empty) in jboss 3.0.4 Trying to put together the minimal webapp to show the bug now. Wanted to go ahead and get the bug posted just in case it's known or something -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-04 14:01 Message: Logged In: YES user_id=44062 Your filter is mapped to /* and you have no servlets. The servlet spec says for getServletPath: The path section that directly corresponds to the mapping which activated this request. This path starts with a / character except in the case where the request is matched with the /* pattern, in which case it is the empty string. So I think we are correct to return the empty string. -- Comment By: Greg Wilkins (gregwilkins) Date: 2003-01-04 13:40 Message: Logged In: YES user_id=44062 Can you attach the source code of your example please. -- Comment By: James Manning (jmm) Date: 2002-11-26 21:09 Message: Logged In: YES user_id=11485 in case it helps, adding another check for getRequestURI shows: (under Tomcat 4.x) 10095 [HttpProcessor[8000][3]] INFO TestFilter - *** getServletPath gives /foo/bar/ack 10095 [HttpProcessor[8000][3]] INFO TestFilter - *** getRequestURI gives /filter/foo/bar/ack under jboss 3.0.4 16:09:28,870 INFO [TestFilter] *** getServletPath gives 16:09:28,870 INFO [TestFilter] *** getRequestURI gives /filter/foo/bar/ack Both are being hit by IE with a url of http://127.0.0.1:8080/filter/foo/bar/ack (port number changed to point to each one) -- Comment By: James Manning (jmm) Date: 2002-11-26 20:13 Message: Logged In: YES user_id=11485 on Tomcat 4.x 0 [HttpProcessor[8000][3]] INFO TestFilter - *** getServletPath gives /foo/bar/ack So this appears (afaict) to be a jboss breakage -- Comment By: James Manning (jmm) Date: 2002-11-26 20:02 Message: Logged In: YES user_id=11485 this is the minimal test-case AFAICT. logging shows: 15:02:14,709 INFO [TestFilter] *** getServletPath gives -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644287&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-662098 ] class loader deadlock new for 3.2Beta3
Bugs item #662098, was opened at 2003-01-04 04:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=662098&group_id=22866 >Category: JBossMX Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dorothy Gantenbein (dgantenbein) >Assigned to: Scott M Stark (starksm) Summary: class loader deadlock new for 3.2Beta3 Initial Comment: Class loader deadlock occurs on Windows XP, Windows 2000 and Linus. Using JDK 1.4.1_01 and JBoss 3.2 Beta3. This was not a problem using JBoss 3.2 Beta1. For us, this deadlock occurs using Cactus' ant task to do automated nightly testing (runservertasks). This ant task starts JBoss, and JBoss freezes during startup at various points. At the bottom of this information is the information about the deadlock from OptimizeIt's thread debugger. The stacktraces to the two threads involved in the deadlock are included (tcpConnection-8080-1 and main). For tcpConnection-8080-1 thread, the resin classes appear in the stacktrace. I have confirmed that the resin classes shown in the stacktrace are NOT holding any monitor on a class. Thread tcpConnection-8080-1 enters monitor java.lang.Class 0xaf35760 first and then org.jboss.mx.loading.UnifiedClassLoader3 0xb124f80 while thread main enters in opposite order. Thread [tcpConnection-8080-1] (Suspended) java.lang.Object.wait(long) line: not available [native method] org.jboss.mx.loading.ClassLoadingTask (java.lang.Object).wait() line: 426 org.jboss.mx.loading.UnifiedClassLoader3.loa dClass(java.lang.String, boolean) line: 175 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClass(java.lang.String) line: 262 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClassInternal (java.lang.String) line: 322 java.lang.ClassLoader.defineClass0 (java.lang.String, byte[], int, int, java.security.ProtectionDomain) line: not available [native method] org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).defineClass(java.lang.String, byte[], int, int, java.security.ProtectionDomain) line: 509 org.jboss.mx.loading.UnifiedClassLoader3 (java.security.SecureClassLoader).defineClass (java.lang.String, byte[], int, int, java.security.CodeSource) line: 123 org.jboss.mx.loading.UnifiedClassLoader3 (java.net.URLClassLoader).defineClass(java.lang.String, sun.misc.Resource) line: 246 java.net.URLClassLoader.access$100 (java.net.URLClassLoader, java.lang.String, sun.misc.Resource) line: 54 java.net.URLClassLoader$1.run() line: 193 java.security.AccessController.doPrivileged (java.security.PrivilegedExceptionAction, java.security.AccessControlContext) line: not available [native method] org.jboss.mx.loading.UnifiedClassLoader3 (java.net.URLClassLoader).findClass(java.lang.String) line: 186 org.jboss.mx.loading.UnifiedClassLoader3 (org.jboss.mx.loading.UnifiedClassLoader).findClass (java.lang.String) line: 444 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClass(java.lang.String, boolean) line: 306 org.jboss.mx.loading.UnifiedClassLoader3 (org.jboss.mx.loading.UnifiedClassLoader).loadClassLoc ally(java.lang.String, boolean) line: 250 org.jboss.mx.loading.UnifiedLoaderRepository 3.loadClassFromClassLoader(java.lang.String, boolean, org.jboss.mx.loading.UnifiedClassLoader) line: 187 org.jboss.mx.loading.LoadMgr.beginLoadTas k(org.jboss.mx.loading.ClassLoadingTask, org.jboss.mx.loading.UnifiedLoaderRepository3) line: 119 org.jboss.mx.loading.UnifiedClassLoader3.loa dClass(java.lang.String, boolean) line: 161 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClass(java.lang.String) line: 262 org.jboss.mx.loading.UnifiedClassLoader3 (java.lang.ClassLoader).loadClassInternal (java.lang.String) line: 322 com.caucho.jsp.JspParser.parse (com.caucho.vfs.ReadStream, java.lang.String, java.lang.String, java.lang.String, com.caucho.vfs.Path, com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoApplication) line: 282 com.caucho.jsp.JspParser.parse (com.caucho.vfs.ReadStream, com.caucho.vfs.Path, java.lang.String, java.lang.String, java.lang.String, com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoApplication, com.caucho.java.LineMap, boolean, java.util.ArrayList) line: 258 com.caucho.jsp.XtpPage.getJspPage (com.caucho.xml.CauchoDocument, javax.xml.transform.Templates, com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoResponse, java.lang.String) line: 602 com.caucho.jsp.XtpPage.compileJspPage (com.caucho.server.http.CauchoRequest, com.caucho.server.http.CauchoResponse, com.caucho.xml.CauchoDocument, javax.xml.transform.Templ
[JBoss-dev] [ jboss-Bugs-660405 ] ServiceController.create( ObjectName, Collectio
Bugs item #660405, was opened at 2002-12-31 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=660405&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Corby (corby) Assigned to: David Jencks (d_jencks) Summary: ServiceController.create( ObjectName, Collectio Initial Comment: SHORT VERSION: If I set my user MBeans to be dependent on the LocalTxConnectionManager, I can no longer successfully recycle my connection pool. LONG VERSION: (I am running JBoss 3.0.4, JDK 1.4.1_01, Win2K) I am using an MBean configuration file, sybase- service.xml, which is laid out almost identically to the hsqldb-service.xml file. It contains a LocalTxCM MBean, which is dependent on a LocalTxDS MBean and a LocalTXPool MBean. Normally, if I touch sybase-service.xml everything works great. ServiceController.install() is called with LocalTxCM, LocalTxDS, and LocalTxPool. ServiceController.create() is called with LocalTxCM, but it waits because the iDependOn beans haven't been created yet. After LocalTxPool is created, we iterate through the dependsOnMe mbeans and the LocalTxCM MBean is created. All is good. But if I introduce my own MBeans that are dependent on the database connection pool, then the ServiceController.create() method behaves differently. I use the following tag in my user MBeans: jboss.jca:service=LocalTxCM,name=sybaseD S Now I can start the JBoss server just fine. But if I recycle the connection pool, here is what happens: ServiceController.install() is called just as before. The ServiceContexts for all three MBeans look fine. In particular, the iDependOn and the dependsOnMe lists are correct, and my userMBeans have been added to the dependsOnMe list for LocalTxCM. When ServiceController.create() method is called on LocalTxCM, it defers again. When ServiceController.create() is called on the other two MBeans, it seems to succeed. The create() methods are successfully executed on these MBeans. Thanks to dependsOnMe, ServiceController.create() is called on LocalTxCM again. But now when we get the ServiceContexts in the iDependOn list for LocalTxCM, they are all defined as state: NOTYETINSTALLED. So LocalTxCM still fails to create because it believes its dependent MBeans have not yet been created. This leads to the predictable log message: ERROR [URLDeploymentScanner] MBeanException: Exception in MBean operation 'checkIncompleteDeployments()' Cause: Incomplete Deployment listing: Packages waiting for a deployer: Incompletely deployed packages: MBeans waiting for classes: MBeans waiting for other MBeans: ... ObjectName: jboss.jca:service=LocalTxCM,name=sybaseDS state: CONFIGURED I Depend On: jboss.jca:service=LocalTxDS,name=sybaseDS jboss.jca:service=LocalTxPool,name=sybaseDS jboss.jca:service=CachedConnectionManager jboss.security:service=JaasSecurityManager jboss.jca:service=RARDeployer jboss.jca:service=LocalTxDS,name=sybaseDS jboss.jca:service=LocalTxPool,name=sybaseDS Depends On Me: (My User MBeans) -- >Comment By: David Jencks (d_jencks) Date: 2003-01-05 05:57 Message: Logged In: YES user_id=60525 Thanks, fixed in 3.0, 3.2, and 4 cvs -- Comment By: Corby (corby) Date: 2002-12-31 21:03 Message: Logged In: YES user_id=25032 The attached files comprise a test case which illustrates the bug -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=660405&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-662569 ] 3.2.0beta3 src archive missing tools\lib
Bugs item #662569, was opened at 2003-01-05 06:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=662569&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul W. Ward (pward) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2.0beta3 src archive missing tools\lib Initial Comment: There's no tools\lib directory in the source archive for jboss 3.2.0 beta 3. I'm assuming I can just copy the directory over from the beta 2 release. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=662569&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-659152 ] Classloading Problem with JavaMail
Bugs item #659152, was opened at 2002-12-27 13:22
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=659152&group_id=22866
Category: JBossMX
Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hunter Hillegas (hunterhillegas)
Assigned to: Scott M Stark (starksm)
Summary: Classloading Problem with JavaMail
Initial Comment:
MacOS X 10.2.3
Apple Java 1.4.1 DP8
When trying to use JavaMail in a Web application, I got
the following exception:
13:13:58,967 WARN [jbossweb] WARNING: Error for
/vagrant/vagrantController?action=sendFriendEmail
java.lang.LinkageError: Class javax/mail/Transport
violates loader constraints
at java.lang.ClassLoader.defineClass0(Native
Method)
at
java.lang.ClassLoader.defineClass(ClassLoader.java:502)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123)
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:250)
at
java.net.URLClassLoader.access$100(URLClassLoader.java:54)
at
java.net.URLClassLoader$1.run(URLClassLoader.java:193)
at
java.security.AccessController.doPrivileged(Native Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:186)
at
org.jboss.mx.loading.UnifiedClassLoader.findClass(UnifiedClassLoader.java:444)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java:250)
at
org.jboss.mx.loading.UnifiedLoaderRepository3.loadClassFromClassLoader(UnifiedLoaderRepository3.java:187)
at
org.jboss.mx.loading.LoadMgr.beginLoadTask(LoadMgr.java:119)
at
org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:161)
at
java.lang.ClassLoader.loadClass(ClassLoader.java:255)
at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
at
javax.mail.Session.getTransport(Session.java:685)
at
javax.mail.Session.getTransport(Session.java:628)
at
javax.mail.Session.getTransport(Session.java:608)
at
javax.mail.Session.getTransport(Session.java:663)
at javax.mail.Transport.send0(Transport.java:154)
at javax.mail.Transport.send(Transport.java:80)
at
com.liberationmedia.beans.EmailBean.(Unknown Source)
at vagrantController.sendFriendEmail(Unknown
Source)
at vagrantController.doPost(Unknown Source)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:272)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:550)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1655)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:542)
at
org.mortbay.http.HttpContext.handle(HttpContext.java:1605)
at
org.mortbay.http.HttpServer.service(HttpServer.java:862)
at org.jboss.jetty.Jetty.service(Jetty.java:497)
at
org.mortbay.http.HttpConnection.service(HttpConnection.java:752)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916)
at
org.mortbay.http.HttpConnection.handle(HttpConnection.java:769)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:202)
at
org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at
org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)
Here is the class loader trace:
[193546,UnifiedClassLoader3,PoolThread-4] released,
holds: 0
[193549,UnifiedClassLoader3,PoolThread-4] attempt(1)
was: true for
:org.jboss.mx.loading.UnifiedClassLoader3@d61ee4{
url=file:/Users/hunter/Unix/jboss-3.2.0beta3/server/default/tmp/deploy/server
/default/conf/jboss-service.xml/1.jboss-service.xml
,addedOrder=2}
[193549,LoadMgr,PoolThread-4] registerLoaderThread,
ucl=org.jboss.mx.loading.UnifiedClassLoader3@d61ee4{
url=file:/Users/hunter/Unix/jboss-3.2.0beta3/server/default/tmp/deploy/server/default/con
f/jboss-service.xml/1.jboss-service.xml ,addedOrder=2},
t=PoolThread-4, prevT=null
[193549,LoadMgr,PoolThread-4] Begin beginLoadTask,
task=org.jboss.mx.loading.ClassLoadingTask@7433e7{classname:
javax.mail.internet.UniqueValue, requestingThread:
PoolThread-4, requestingClassLo
ader: org.jboss.mx.loading.UnifiedClassLoader3@d61ee4{
url=file:/Users/hunter/Unix/jboss-3.2.0beta3/server/default/tmp/deploy/server/default/conf/jboss-service.xml/1.jboss-service.xml
,addedOrde
r=2}, loadedClass: null, loadOrder: 2147483647,
loadException: null, threadTaskCount: 0, state: 0}
[193551,LoadMgr,PoolThread-4] End beginLoadTask,
loadClassFromClassLoader
[193552,LoadMgr,PoolThread-4] Begin endLoadTask,
task=org.jboss.mx.loading.ClassLoadingTas
[JBoss-dev] [ jboss-Bugs-618410 ] NPE during deploying WAR
Bugs item #618410, was opened at 2002-10-03 23:48
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=618410&group_id=22866
Category: JBossWeb
Group: v3.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Vladimir Korenev (vkorenev)
Assigned to: Nobody/Anonymous (nobody)
Summary: NPE during deploying WAR
Initial Comment:
OS: Win2000
JDK: 1.4.1-rc
JBoss v. 3.0.3 with Jetty
An error occures when JBoss starts:
10:03:37,396 ERROR [URLDeploymentScanner]
Failed to deploy: org.jboss.deployment
.scanner.URLDeploymentScanner$DeployedURL@64
67598e{ url=file:/D:/java/jboss-3.0.
3/server/default/deploy/cboss.ear/,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: -
nested throwable: (java.lang.NullPoi
nterException)
at org.jboss.jetty.Jetty.deploy(Jetty.java:434)
at org.jboss.jetty.JettyService.performDeploy
(JettyService.java:243)
at org.jboss.web.AbstractWebContainer.start
(AbstractWebContainer.java:30
0)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:802)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:794)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:580)
at
sun.reflect.GeneratedMethodAccessor9.invoke
(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.i
nvoke(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy4.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScann
er.deploy(URLDeploymen
tScanner.java:427)
at
org.jboss.deployment.scanner.URLDeploymentScann
er.scanDirectory(URLDe
ploymentScanner.java:648)
at
org.jboss.deployment.scanner.URLDeploymentScann
er.scan(URLDeploymentS
canner.java:499)
at
org.jboss.deployment.scanner.AbstractDeploymentS
canner.startService(A
bstractDeploymentScanner.java:261)
at org.jboss.system.ServiceMBeanSupport.start
(ServiceMBeanSupport.java:1
64)
at
sun.reflect.GeneratedMethodAccessor7.invoke
(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.i
nvoke(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at
org.jboss.system.ServiceController$ServiceProxy.inv
oke(ServiceControl
ler.java:976)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start
(ServiceController.java:397)
at
sun.reflect.GeneratedMethodAccessor6.invoke
(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.i
nvoke(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy3.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start
(SARDeployer.java:249)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:802)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:580)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:564)
at
sun.reflect.NativeMethodAccessorImpl.invoke0
(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.i
nvoke(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.system.server.ServerImpl.doStart
(ServerImpl.java:324)
at org.jboss.system.server.ServerImpl.start
(ServerImpl.java:221)
at org.jboss.Main.boot(Main.java:148)
at org.jboss.Main$1.run(Main.java:381)
at java.lang.Thread.run(Thread.java:536)
Caused by: java.lang.NullPointerException
at org.mortbay.j2ee.session.Manager.start
(Manager.java:159)
at org.mortbay.jetty.servlet.ServletHandler.start
(ServletHandler.java:40
9)
at
org.mortbay.jetty.servlet.WebApplicationHandler.sta
rt(WebApplic
[JBoss-dev] [ jboss-Bugs-663114 ] MarshallException when accessing remote bean
Bugs item #663114, was opened at 2003-01-06 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663114&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Maxim (kimerinn) Assigned to: Nobody/Anonymous (nobody) Summary: MarshallException when accessing remote bean Initial Comment: Hi! Scenario: 1) I have two session beans A and B, each of them have remote interfaces. A obtains home & remote interface of bean B and invokes method B.hello(). 2) When both beans are locating on the same machine, all works Ok. 3) When bean A is hosting on one computer and bean B on second, bean A obtains home interface of bean B and obtain exception when creating remote interface of bean B. 4) When the bean B is accesed fom another computer through application client, all works Ok. Here is full stack trace: = 13:16:12,169 ERROR [STDERR] java.rmi.MarshalException: error marshalling arguments; nested exception is: java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148) 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:377) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1172) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:268) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:106) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:138) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:108) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:77) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:198) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) 13:16:12,220 ERROR [STDERR] at $Proxy25.create(Unknown Source) 13:16:12,220 ERROR [STDERR] at aside.ABean.testB(ABean.java:46) 13:16:12,220 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,220 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660) 13:16:12,220 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:712) 13:16:12,240 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 13:16:12,240 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) 13:16:12,240 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:152) 13:16:12,240 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:148) 13:16:12,240 ERROR
[JBoss-dev] [ jboss-Bugs-663114 ] MarshallException when accessing remote bean
Bugs item #663114, was opened at 2003-01-06 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663114&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Maxim (kimerinn) Assigned to: Nobody/Anonymous (nobody) Summary: MarshallException when accessing remote bean Initial Comment: Hi! Scenario: 1) I have two session beans A and B, each of them have remote interfaces. A obtains home & remote interface of bean B and invokes method B.hello(). 2) When both beans are locating on the same machine, all works Ok. 3) When bean A is hosting on one computer and bean B on second, bean A obtains home interface of bean B and obtain exception when creating remote interface of bean B. 4) When the bean B is accesed fom another computer through application client, all works Ok. Here is full stack trace: = 13:16:12,169 ERROR [STDERR] java.rmi.MarshalException: error marshalling arguments; nested exception is: java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148) 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:377) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1172) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:268) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:106) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:138) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:108) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:77) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:198) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) 13:16:12,220 ERROR [STDERR] at $Proxy25.create(Unknown Source) 13:16:12,220 ERROR [STDERR] at aside.ABean.testB(ABean.java:46) 13:16:12,220 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,220 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660) 13:16:12,220 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:712) 13:16:12,240 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 13:16:12,240 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) 13:16:12,240 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:152) 13:16:12,240 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:148) 13:16:12,240 ERROR
[JBoss-dev] [ jboss-Bugs-663228 ] IllegalState on CMP load
Bugs item #663228, was opened at 2003-01-06 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663228&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: IllegalState on CMP load Initial Comment: JBoss3.0.4 I have a cmp entity bean that has 5 fields tied to blobs and each contains 100-200k. There are 5 rows in my table. I have a jsp page that lists all 5 and 2 field about each. Before i put the data in the fields my jsp page worked fine. Then in put the data in and the first time (after a deployement) the page is displayed perfectly, albeight a tad slow (probably due to the db data transfer), but the 2nd and all subsequent times when i attempt to view this page i get the following error. It appears that i am trying to get the primaryKey method on the bean. 11:30:22,833 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: removing bean lock and it has tx set!Funds myPrimaryKey at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.r emoveRef(QueuedPessimisticEJBLock.java:427) at org.jboss.ejb.BeanLockManager.removeLockRef (BeanLockManager.java:107) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockInterceptor.java:124) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke (EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:204) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.EntityProxy.invoke (EntityProxy.java:38) at $Proxy92.getFundKey(Unknown Source) 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:324) at org.apache.commons.beanutils.PropertyUtils.getSimple Property(PropertyUtils.java:1095) at org.apache.commons.beanutils.PropertyUtils.getNested Property(PropertyUtils.java:694) at org.apache.commons.beanutils.PropertyUtils.getPropert y(PropertyUtils.java:724) at org.apache.struts.util.RequestUtils.lookup (RequestUtils.java:702) at org.apache.struts.taglib.html.BaseFieldTag.doStartTag (BaseFieldTag.java:192) at org.apache.struts.taglib.html.HiddenTag.doStartTag (HiddenTag.java:123) at org.apache.jsp.availablefunds$jsp._jspService (availablefunds$jsp.java:352) at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper. service(JspServlet.java:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service (JspServlet.java:473) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:366) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatc h(WebApplicationHandler.java:293) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:581) at org.mortbay.http.HttpContext.handle (HttpContext.java:1687) at org.mortbay.jetty.servlet.WebApplicationContext.handle (WebApplicationContext.java:544) at org.mortbay.http.HttpContext.handle (HttpContext.java:1637) at org.mortbay.http.HttpServer.service (HttpServer.java:875) at org.jboss.jetty.Jetty.service(Jetty.java:543) at org.mortbay.http.HttpConnection.service (HttpConnection.java:806) at org.mortbay.http.HttpConnection.handleNext (HttpConnection.java:956) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:823) at org.mortbay.http.SocketListener.handleConnection (SocketListener.java:203) at org.mortbay.util.ThreadedServer.handle (ThreadedServer.java:290) at org.mortbay.util.ThreadPool$JobRunner.run (ThreadPool.java:743) at java.lang.Thread.run(Thread.java:536) 11:30:22,849 WARN [jbossweb] WARNING: Exception for /admin/funds/availablefunds.jsp javax.servlet.jsp.JspException: Excepti
[JBoss-dev] [ jboss-Bugs-663283 ] NamingContext.lookup(Name) changes Name parameter
Bugs item #663283, was opened at 2003-01-06 19:33
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663283&group_id=22866
Category: None
Group: v4.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Rod Burgett (rodburgett)
Assigned to: Nobody/Anonymous (nobody)
Summary: NamingContext.lookup(Name) changes Name parameter
Initial Comment:
OS: Win2K, v5.0
JDK: Sun 1.3.1_04
Category: JBossNS
1) The 'Object lookup(javax.naming.Name name)'
method in the org.jnp.interfaces.NamingContext class
has a side effect of changing the state of the input Name
instance when the input Name includes a scheme prefix
such as "java:". For example, using a Name instance
created from "java:comp/env", display name.toString()
before and after calling ctx.lookup(name). The displayed
strings are different.
2) The org.jnp.client.Main tester for this class does not
currently check for this side effect.
Proposed fix 2):
Applying the following 'diff' to org.jnp.client.Main.java will
expose bug 1) above.
diff -r1.7 Main.java
141,143c141,156
< server = ctx.lookup"jnp://localhost/test/server2");
< System.out.println("jnp://localhost/test/server2
lookup:"+server);
<
---
> //...updated 03-jan-2003, rodB, to check lookup using
Name and side effects
> String
svr2NameString "jnp://localhost/test/server2";
> server = ctx.lookup(svr2NameString);
> System.out.println
(svr2NameString+"lookup:"+server);
> Name svr2Name = ctx.getNameParser
(svr2NameString).parse(svr2NameString);
> Name svr2NameClone = (Name) svr2Name.clone
();
> server = ctx.lookup(svr2Name);
> System.out.println(svr2NameString+" lookup,
using Name:"+server);
> if ( ! svr2Name.equals( svr2NameClone) )
> {
> System.out.println("Oops! ctx.lookup()
changed state of Name " +
>"parameter
from "+svr2NameClone.toString() +
>") to ("+svr2Name.toString()+")");
> }
> //...end of 03-jan-2003 changes, rodB
>
Proposed fix 1):
Applying the following 'diff' to
org.jnp.interfaces.NamingContext.java will correct bug 1)
above.
diff -r1.23 NamingContext.java
357a358,359
> //...one line below added 03-jan-2003, rodB, to avoid
side effects on name
> name = (Name) name.clone ();
404a407,408
> //...one line below added 03-jan-2003, rodB, to avoid
side effects on name
> name = (Name) name.clone ();
452a457,458
> //...one line below added 03-jan-2003, rodB, to avoid
side effects on name
> name = (Name) name.clone ();
624a631,632
> //...one line below added 03-jan-2003, rodB, to avoid
side effects on name
> name = (Name) name.clone ();
667a676,677
> //...one line below added 03-jan-2003, rodB, to avoid
side effects on name
> name = (Name) name.clone ();
697a708,709
> //...one line below added 03-jan-2003, rodB, to avoid
side effects on name
> name = (Name) name.clone ();
798a811,812
> //...one line below added 03-jan-2003, rodB, to avoid
side effects on name
> name = (Name) name.clone ();
Why so many identical new lines? Many of the
javax.naming.Context interface methods, e.g. bind,
rebind, list, unbind, use a Name instance for input. In
this implementation, many follow a similar pattern to
ensure common handling of the input Name.
Why not fix it in just one place? The common handling
pattern includes calling getEnv(), a private method,
which in turn calls parseNameForScheme(), a static
method with package visibility. It is
parseNameForScheme that updates it's input Name, but
lookup, list, bind, etc. make subsequent calls to
getAbsoluteName(), which will operate properly only on
a Name exhibiting this side effect.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663283&group_id=22866
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-634165 ] RollingLogged PM can't roll logs
Bugs item #634165, was opened at 2002-11-05 15:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=634165&group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Corby (corby) Assigned to: Nobody/Anonymous (nobody) Summary: RollingLogged PM can't roll logs Initial Comment: I switched over to the new rolling logged file persistence manager for JBossMQ, and ran my application. When it came time to roll logs, I crapped out with the following: org.jboss.mq.SpyJMSException: Error rolling over logs to new files.; - nested throwable: (org.jboss.mq.SpyJMSException: Could not open the queue's tranaction log: D:\Apps\jboss\server\allocations\db\jbossmq\file\transactions.dat259; - nested throwable: (java.io.FileNotFoundException: D:\Apps\jboss\server\allocations\db\jbossmq\file\transactions.dat259 (Too many open files))) at org.jboss.mq.pm.rollinglogged.PersistenceManager.rollOverLogs(Persist enceManager.java:713) at org.jboss.mq.pm.rollinglogged.PersistenceManager.checkRollOver(Persis tenceManager.java:685) at org.jboss.mq.pm.rollinglogged.PersistenceManager.add(PersistenceManag er.java:328) at org.jboss.mq.server.PersistentQueue.addMessage(PersistentQueue.java:4 1) at org.jboss.mq.server.JMSQueue.addMessage(JMSQueue.java:116) at org.jboss.mq.server.JMSDestinationManager.addMessage(JMSDestinationMa nager.java:398) at org.jboss.mq.server.JMSDestinationManager.addMessage(JMSDestinationMa nager.java:376) at org.jboss.mq.server.JMSServerInvoker.addMessage(JMSServerInvoker.java :137) at org.jboss.mq.il.jvm.JVMServerIL.addMessage(JVMServerIL.java:137) at org.jboss.mq.Connection.sendToServer(Connection.java:1119) at org.jboss.mq.SpySession.sendMessage(SpySession.java:654) at org.jboss.mq.SpyQueueSender.internalSend(SpyQueueSender.java:118) at org.jboss.mq.SpyQueueSender.send(SpyQueueSender.java:68) -- Comment By: Elias Ross (genman) Date: 2003-01-06 21:43 Message: Logged In: YES user_id=556458 The roll-over size is set too small, and cannot be configured. I created a patch which I submitted awhile ago: https://sourceforge.net/tracker/?func=detail&aid=621702&group_id=22866&atid=376687 -- Comment By: Corby (corby) Date: 2002-11-05 15:46 Message: Logged In: YES user_id=25032 This is running JBoss 3.0.4 under Windows 2000, JDK 1.4.1_01 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=634165&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-583619 ] invalid LOC header (bad signature)
Bugs item #583619, was opened at 2002-07-19 04:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=583619&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Russell Black (rblack) Assigned to: Nobody/Anonymous (nobody) Summary: invalid LOC header (bad signature) Initial Comment: With JBoss-3.0.0 / Jetty, when hot-deploying a new war over an existing one, an "invalid LOC header (bad signature)" error occurs, with a stack trace that looks something like this 2002-07-17 14:52:00,050 ERROR [org.jboss.deployment.MainDeployer] could not start deployment: njar:file:/C:/jboss3/server/default/tmp/deploy/server/defaul t/deploy/macausms.ear/59.macausms.ear^/macausms.w ar java.lang.InternalError: jzentry == 0, jzfile = 7857776, total = 37, name = C:\WINDOWS\TEMP\Jetty__80_sendsms_eric- chow_com__\webapp\WEB-INF\lib\macausms-web.jar, i = 33, message = invalid LOC header (bad signature) at java.util.zip.ZipFile$2.nextElement(ZipFile.java:303) at java.util.jar.JarFile$1.nextElement(JarFile.java:200) at org.apache.jasper.compiler.TldLocationsCache.tldConfigJ ar(TldLocationsCache.java:234) ... This error is consistenly reproducable. For more details and steps to reproduce, see http://jboss.org/forums/thread.jsp? forum=52&thread=17978 -- Comment By: Rickard Öberg (rickardoberg) Date: 2003-01-07 07:43 Message: Logged In: YES user_id=28931 Are there any plans to fix this? Until it is, JBoss hot deploy is just broken. For development I'd guess most people who have large apps use exploded EAR's/WAR's, and this bug happens all the time, so a reboot is needed whenever an update is made. It's just really bad. For production it is also convenient to use exploded EAR's since it allows easy patching instead of having to replace the entire EAR (which in our case is getting pretty large). -- Comment By: Scott M Stark (starksm) Date: 2002-07-26 21:21 Message: Logged In: YES user_id=175228 This will happen if the update is not done as an atomic operation and the deployer thread tries to read the incompletely updated war. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=583619&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-638724 ] LdapLoginModule not support MS ActiveDir
Bugs item #638724, was opened at 2002-11-14 14:59
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638724&group_id=22866
Category: JBossSX
Group: v3.0 Rabbit Hole
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Randy Shoup (rshoup)
Assigned to: Scott M Stark (starksm)
Summary: LdapLoginModule not support MS ActiveDir
Initial Comment:
OS: Windows2000
JDK: 1.4
LdapLoginModule in JBoss 3.0.3 does not have sufficient
flexibility to support reading user-role information
from user-Group assignments in Microsoft ActiveDirectory.
In the user record, ActiveDirectory stores the DNs of
the Groups to which the user has been assigned.
LdapLoginModule in JBoss 3.0.3 assumes that the role
attribute of a user record would be the role name
instead of a DN to a role object.
I submitted patch #638718 which fixes this issue.
This patch adds two additional config parameters:
roleAttributeIsDN: whether role attribute is a DN or a
role name
roleNameAttributeId: the name of the role name
attribute of the role object
If `roleAttributeIsDN` is true, the patch looks up the
object corresponding to the role DN, then gets the
attribute named by `roleNameAttributeId` to provide the
role name.
For ActiveDirectory, the appropriate login-module
config settings would look like:
testLdapToActiveDirectory {
org.jboss.security.auth.spi.LdapLoginModule required
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
java.naming.provider.url="ldap://ldaphost.jboss.org:1389/";
java.naming.security.authentication=simple
rolesCtxDN=cn=Users,dc=ldaphost,dc=jboss,dc=org
uidAttributeID=userPrincipalName
roleAttributeID=memberOf
roleAttributeIsDN=true
roleNameAttributeID=name
};
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638724&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663859 ] Deadlock in shutdown hooks when interrupting startup
Bugs item #663859, was opened at 2003-01-07 11:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663859&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Dave Marquard (lurp) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock in shutdown hooks when interrupting startup Initial Comment: Steps to reproduce: While JBoss is starting up (i.e., deploying services, ejbs, etc.), hit Ctrl+C to halt the VM. About two thirds of the time a deadlock will happen in the shutdown hooks. JBoss version: 3.0.5rc1 JDK version: 1.4.1_01 OS: Windows XP The thread dump of the deadlock is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663859&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664081 ] JCA rars packaging causes IllegalAccessError
Bugs item #664081, was opened at 2003-01-07 15:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664081&group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: David Jencks (d_jencks) Summary: JCA rars packaging causes IllegalAccessError Initial Comment: An java.lang.IllegalAccessError: tried to access method org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnectionFactory.getConnectionProperties (Ljavax/security/auth/Subject;Ljavax/resource/spi/Conne ctionRequestInfo;)Ljava/util/Properties; from class org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection has been reported and this is an issue with the jca classes being deployed redundantly: lib 634>jar -tf ra-xa-libs.jar | grep BaseWrapper org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnection.class org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnectionFactory.class lib 635>jar -tf local-ra-jdbc-libs.jar | grep BaseWrapper org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnection.class org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnectionFactory.class Under a usage pattern that happens to load the BaseWrapperManagedConnectionFactory class from the local-ra-jdbc-libs.jar, while the BaseWrapperManagedConnection class is later loaded from the ra-xa-libs.jar, because two different class loaders are involved, the package protected access fails. These classes cannot be deployed redundantly in the same scope in different jars as there is no way for the ULR to ensure that the same class loader handles the classes with package protected access. The jboss-xa.rar and jboss-local-jdbc.rar need to be refactored to fix this. > Here's the exception: > > 16:17:58,415 ERROR [LogInterceptor] Unexpected Error: > java.lang.IllegalAccessError: tried to access method > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnectionFactory.getConnectionProperties (Ljavax/security/auth/Subject;Ljavax/resource/spi/Conne ctionRequestInfo;)Ljava/util/Properties; > from class org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection > at > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.checkIdentity (BaseWrapperManagedConnection.java:295) > at > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.getConnection (BaseWrapperManagedConnection.java:188) > at > org.jboss.resource.connectionmanager.BaseConnection Manager2.allocateConnection (BaseConnectionManager2.java:596) > at > org.jboss.resource.connectionmanager.BaseConnection Manager2$ConnectionManagerProxy.allocateConnection (BaseConnectionManager2.java:885) > at > org.jboss.resource.adapter.jdbc.WrapperDataSource.get Connection(WrapperDataSource.java:102) ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664081&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664081 ] JCA rars packaging causes IllegalAccessError
Bugs item #664081, was opened at 2003-01-07 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664081&group_id=22866 Category: JBossCX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: David Jencks (d_jencks) Summary: JCA rars packaging causes IllegalAccessError Initial Comment: An java.lang.IllegalAccessError: tried to access method org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnectionFactory.getConnectionProperties (Ljavax/security/auth/Subject;Ljavax/resource/spi/Conne ctionRequestInfo;)Ljava/util/Properties; from class org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection has been reported and this is an issue with the jca classes being deployed redundantly: lib 634>jar -tf ra-xa-libs.jar | grep BaseWrapper org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnection.class org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnectionFactory.class lib 635>jar -tf local-ra-jdbc-libs.jar | grep BaseWrapper org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnection.class org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnectionFactory.class Under a usage pattern that happens to load the BaseWrapperManagedConnectionFactory class from the local-ra-jdbc-libs.jar, while the BaseWrapperManagedConnection class is later loaded from the ra-xa-libs.jar, because two different class loaders are involved, the package protected access fails. These classes cannot be deployed redundantly in the same scope in different jars as there is no way for the ULR to ensure that the same class loader handles the classes with package protected access. The jboss-xa.rar and jboss-local-jdbc.rar need to be refactored to fix this. > Here's the exception: > > 16:17:58,415 ERROR [LogInterceptor] Unexpected Error: > java.lang.IllegalAccessError: tried to access method > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnectionFactory.getConnectionProperties (Ljavax/security/auth/Subject;Ljavax/resource/spi/Conne ctionRequestInfo;)Ljava/util/Properties; > from class org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection > at > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.checkIdentity (BaseWrapperManagedConnection.java:295) > at > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.getConnection (BaseWrapperManagedConnection.java:188) > at > org.jboss.resource.connectionmanager.BaseConnection Manager2.allocateConnection (BaseConnectionManager2.java:596) > at > org.jboss.resource.connectionmanager.BaseConnection Manager2$ConnectionManagerProxy.allocateConnection (BaseConnectionManager2.java:885) > at > org.jboss.resource.adapter.jdbc.WrapperDataSource.get Connection(WrapperDataSource.java:102) -- >Comment By: David Jencks (d_jencks) Date: 2003-01-08 03:28 Message: Logged In: YES user_id=60525 I've fixed this in 3.2. I don't think it is a problem in 3.0.x since there are no shared classes between the adapters (different xa adapter than 3.2 and 4). I haven't fixed it in 4.0 because once jca 1.5 deployment is written both adapters can be packaged together, eliminating the extra jar. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664081&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664081 ] JCA rars packaging causes IllegalAccessError
Bugs item #664081, was opened at 2003-01-07 15:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664081&group_id=22866 Category: JBossCX Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: David Jencks (d_jencks) Summary: JCA rars packaging causes IllegalAccessError Initial Comment: An java.lang.IllegalAccessError: tried to access method org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnectionFactory.getConnectionProperties (Ljavax/security/auth/Subject;Ljavax/resource/spi/Conne ctionRequestInfo;)Ljava/util/Properties; from class org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection has been reported and this is an issue with the jca classes being deployed redundantly: lib 634>jar -tf ra-xa-libs.jar | grep BaseWrapper org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnection.class org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnectionFactory.class lib 635>jar -tf local-ra-jdbc-libs.jar | grep BaseWrapper org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnection.class org/jboss/resource/adapter/jdbc/BaseWrapperManagedC onnectionFactory.class Under a usage pattern that happens to load the BaseWrapperManagedConnectionFactory class from the local-ra-jdbc-libs.jar, while the BaseWrapperManagedConnection class is later loaded from the ra-xa-libs.jar, because two different class loaders are involved, the package protected access fails. These classes cannot be deployed redundantly in the same scope in different jars as there is no way for the ULR to ensure that the same class loader handles the classes with package protected access. The jboss-xa.rar and jboss-local-jdbc.rar need to be refactored to fix this. > Here's the exception: > > 16:17:58,415 ERROR [LogInterceptor] Unexpected Error: > java.lang.IllegalAccessError: tried to access method > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnectionFactory.getConnectionProperties (Ljavax/security/auth/Subject;Ljavax/resource/spi/Conne ctionRequestInfo;)Ljava/util/Properties; > from class org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection > at > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.checkIdentity (BaseWrapperManagedConnection.java:295) > at > org.jboss.resource.adapter.jdbc.BaseWrapperManagedC onnection.getConnection (BaseWrapperManagedConnection.java:188) > at > org.jboss.resource.connectionmanager.BaseConnection Manager2.allocateConnection (BaseConnectionManager2.java:596) > at > org.jboss.resource.connectionmanager.BaseConnection Manager2$ConnectionManagerProxy.allocateConnection (BaseConnectionManager2.java:885) > at > org.jboss.resource.adapter.jdbc.WrapperDataSource.get Connection(WrapperDataSource.java:102) -- >Comment By: Scott M Stark (starksm) Date: 2003-01-07 19:48 Message: Logged In: YES user_id=175228 Ok, thanks. I don't care about 4.0 at this point -- Comment By: David Jencks (d_jencks) Date: 2003-01-07 19:28 Message: Logged In: YES user_id=60525 I've fixed this in 3.2. I don't think it is a problem in 3.0.x since there are no shared classes between the adapters (different xa adapter than 3.2 and 4). I haven't fixed it in 4.0 because once jca 1.5 deployment is written both adapters can be packaged together, eliminating the extra jar. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664081&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-638488 ] Incorrect SQL with OR and IS NOT EMPTY
Bugs item #638488, was opened at 2002-11-14 08:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638488&group_id=22866 Category: JBossCMP Group: CVS HEAD >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Boynes (jboynes) >Assigned to: Jeremy Boynes (jboynes) Summary: Incorrect SQL with OR and IS NOT EMPTY Initial Comment: Opening this as 621270 has been closed. Incorrect SQL is generated for EJB-QL where IS NOT EMPTY is used in a OR condition such as: SELECT OBJECT(p) FROM parent p WHERE p.children IS NOT EMPTY OR p.value = ?1 generates SELECT t0_p.id FROM Parent t0_p, Child t1_p_children WHERE ((1=1) OR t0_p.value = ?) -- < oops AND (t0_p.id=t1_p_children.parent) -- >Comment By: Jeremy Boynes (jboynes) Date: 2003-01-07 20:50 Message: Logged In: YES user_id=378919 Fixed in Branch_3_2 and HEAD Now provided the database supports subqueries they will always be used. If the database does not (e.g. MySQL), then a query like: SELECT DISTINCT Parent.ID FROM Parent LEFT JOIN Child ON (Parent.ID = Child.Parent) WHERE Child.ID IS NOT NULL OR Parent.value = ? will be generated. This takes a performance hit but generates correct results except if the query is meant to return duplicate values - SQL requires subqueries to handle that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=638488&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-642609 ] Deployment error with empty relation-nam
Bugs item #642609, was opened at 2002-11-22 16:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=642609&group_id=22866 Category: JBossCMP Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Boynes (jboynes) >Assigned to: Jeremy Boynes (jboynes) Summary: Deployment error with empty relation-nam Initial Comment: Sun's PetStore 1.3.1 application contains empty ejb-relation-name entries such as: ... Presumably this deploys fine on the reference implementation. However, JBoss returns an error saying that the ejb-relation-name must be unique. According to the EJB2.0 spec: "The ejb-relation-name element provides a unique name for a relationship." In EJB2.1 this is expanded to "The name of the relationship, if specified, is unique within the ejb-jar file." Note the "if specified" IMHO the spec isn't very precise here but, for compatibility with the RI and PetStore, JBoss should treat empty ejb-relation-name elements as if they were not specified. -- >Comment By: Jeremy Boynes (jboynes) Date: 2003-01-07 22:43 Message: Logged In: YES user_id=378919 Fixed in Branch_3_2 and HEAD ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=642609&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664322 ] EJBQL Date Comparison Broken
Bugs item #664322, was opened at 2003-01-08 12:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Daniel Spilker (nichdiemama) Assigned to: Nobody/Anonymous (nobody) Summary: EJBQL Date Comparison Broken Initial Comment: When trying to find some CMP entity beans by a finder method which takes a java.util.Date as a parameter and does an equals compaision with that parameter to a cmp-field, the returned result is always empty. EJBQL: SELECT Object(r) FROM TimeRecord AS r WHERE r.date=?1 "<" and ">" work fine, I also tried different databases it's always the same problem. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664322 ] EJBQL Date Comparison Broken
Bugs item #664322, was opened at 2003-01-08 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Daniel Spilker (nichdiemama) >Assigned to: Alexey Loubyansky (loubyansky) Summary: EJBQL Date Comparison Broken Initial Comment: When trying to find some CMP entity beans by a finder method which takes a java.util.Date as a parameter and does an equals compaision with that parameter to a cmp-field, the returned result is always empty. EJBQL: SELECT Object(r) FROM TimeRecord AS r WHERE r.date=?1 "<" and ">" work fine, I also tried different databases it's always the same problem. -- >Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 14:29 Message: Logged In: YES user_id=543482 Could you, please, provide a testcase that shows it? It works for me. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663228 ] IllegalState on CMP load
Bugs item #663228, was opened at 2003-01-06 19:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663228&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: IllegalState on CMP load Initial Comment: JBoss3.0.4 I have a cmp entity bean that has 5 fields tied to blobs and each contains 100-200k. There are 5 rows in my table. I have a jsp page that lists all 5 and 2 field about each. Before i put the data in the fields my jsp page worked fine. Then in put the data in and the first time (after a deployement) the page is displayed perfectly, albeight a tad slow (probably due to the db data transfer), but the 2nd and all subsequent times when i attempt to view this page i get the following error. It appears that i am trying to get the primaryKey method on the bean. 11:30:22,833 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: removing bean lock and it has tx set!Funds myPrimaryKey at org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock.r emoveRef(QueuedPessimisticEJBLock.java:427) at org.jboss.ejb.BeanLockManager.removeLockRef (BeanLockManager.java:107) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockInterceptor.java:124) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke (EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransacti ons(TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke (TxInterceptorCMT.java:60) at org.jboss.ejb.plugins.SecurityInterceptor.invoke (SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:204) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.inv oke(BaseLocalContainerInvoker.java:301) at org.jboss.ejb.plugins.local.EntityProxy.invoke (EntityProxy.java:38) at $Proxy92.getFundKey(Unknown Source) 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:324) at org.apache.commons.beanutils.PropertyUtils.getSimple Property(PropertyUtils.java:1095) at org.apache.commons.beanutils.PropertyUtils.getNested Property(PropertyUtils.java:694) at org.apache.commons.beanutils.PropertyUtils.getPropert y(PropertyUtils.java:724) at org.apache.struts.util.RequestUtils.lookup (RequestUtils.java:702) at org.apache.struts.taglib.html.BaseFieldTag.doStartTag (BaseFieldTag.java:192) at org.apache.struts.taglib.html.HiddenTag.doStartTag (HiddenTag.java:123) at org.apache.jsp.availablefunds$jsp._jspService (availablefunds$jsp.java:352) at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper. service(JspServlet.java:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service (JspServlet.java:473) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:366) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatc h(WebApplicationHandler.java:293) at org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:581) at org.mortbay.http.HttpContext.handle (HttpContext.java:1687) at org.mortbay.jetty.servlet.WebApplicationContext.handle (WebApplicationContext.java:544) at org.mortbay.http.HttpContext.handle (HttpContext.java:1637) at org.mortbay.http.HttpServer.service (HttpServer.java:875) at org.jboss.jetty.Jetty.service(Jetty.java:543) at org.mortbay.http.HttpConnection.service (HttpConnection.java:806) at org.mortbay.http.HttpConnection.handleNext (HttpConnection.java:956) at org.mortbay.http.HttpConnection.handle (HttpConnection.java:823) at org.mortbay.http.SocketListener.handleConnection (SocketListener.java:203) at org.mortbay.util.ThreadedServer.handle (ThreadedServer.java:290) at org.mortbay.util.ThreadPool$JobRunner.run (ThreadPool.java:743) at java.lang.Thread.run(Thread.java:536) 11:30:22,849 WARN [jbossweb] WARNING: Exception for /admin/funds/availablefunds.jsp javax.servlet.jsp.JspException: Excepti
[JBoss-dev] [ jboss-Bugs-664373 ] "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work
Bugs item #664373, was opened at 2003-01-08 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Nobody/Anonymous (nobody) Summary: "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work Initial Comment: Situation: one-to-one relationship between Customer and HomeAddress. Some Customers do have a home address (=> cust.getHomeAddress() != null) while others don't (=> cust.getHomeAddress() == null) Problem: queries such as: SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NULL or SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NOT NULL always return an empty collection. This was working under 3.0.x (maybe it still works) but it doesn't work under a fresh Branch_3_2 snapshot from this morning. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-664390 ] for informix auto-generated serial value
Patches item #664390, was opened at 2003-01-08 08:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=664390&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Shneyderman (ashneyderman)
Assigned to: Nobody/Anonymous (nobody)
Summary: for informix auto-generated serial value
Initial Comment:
This command will allow automatic assignment of the
PK field of CMP entity, that is Informix (7.3* IDS) serial
field as its PK.
This was tested using the JDBC Driver provided by IBM
that can be downloaded at
http://www14.software.ibm.com/webapp/download/produc
t.jsp?type=b&id=MBEN-
4ZKP2T&s=z&cat=&S_TACT=&S_CMP=
The patch includes:
1. command itself in the
org/jboss/ejb/plugins/cmp/jdbc/informix/JDBCInformixCre
ateCommand.{java and class}
2. addition to the build.xml needed to build correctly in
build.xml file. Note that only the addtion to build.xml is
shown in this file.
3. addition to standardjbosscmp-jdbc.xml to be able to
use the command in standardjbosscmp-jdbc.xml file.
Note that only the addtion to the xml is shown in this file.
4. ifxjdbc.jar has to go to thirdparty/infromix/informix/lib
to build correctly
If you do not need to be able to build the command
yourself you will only need files (1) and (3). Put (1) in the
classpath where Jboss will be able to see it; make
needed addition to the standardjbosscmp-jdbc.xml
shown in (3); and I assume you already have the
ifxjdbc.jar available.
That is it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=664390&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664322 ] EJBQL Date Comparison Broken
Bugs item #664322, was opened at 2003-01-08 12:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Daniel Spilker (nichdiemama) Assigned to: Alexey Loubyansky (loubyansky) Summary: EJBQL Date Comparison Broken Initial Comment: When trying to find some CMP entity beans by a finder method which takes a java.util.Date as a parameter and does an equals compaision with that parameter to a cmp-field, the returned result is always empty. EJBQL: SELECT Object(r) FROM TimeRecord AS r WHERE r.date=?1 "<" and ">" work fine, I also tried different databases it's always the same problem. -- >Comment By: Daniel Spilker (nichdiemama) Date: 2003-01-08 15:18 Message: Logged In: YES user_id=279538 OK, it works for me too. When constructing a test case I realized that I ran into the usual millisecond bug. Sorry for bothering you, Daniel -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 13:29 Message: Logged In: YES user_id=543482 Could you, please, provide a testcase that shows it? It works for me. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664400 ] JNDIView.listXML() produces ill-formed XML
Bugs item #664400, was opened at 2003-01-08 14:19
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664400&group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rod Burgett (rodburgett)
Assigned to: Nobody/Anonymous (nobody)
Summary: JNDIView.listXML() produces ill-formed XML
Initial Comment:
The 'String listXML()' method in the
org.jboss.naming.JNDIView class produces XML file that
is not well-formed if an error is encountered during
recursive examination of Context instances. Error
handling in the private listXML(Context, StringBuffer)
method results in a tag with a matching
tag.
Reproducing the bug symptoms requires an error to be
encountered during Context.list(). In my vanilla
installation of JBoss, the java:TimedCacheFactory
context produced this error, producing the following XML:
timedCacheFactory
javax.nameing.Context
Failed to lookup: timedCacheFActory,
errmsg=org.jboss.util.TimedCachePolicy
Subsequent XML output goes on to list other JNDI
entries, but the lack of tag following the
tag produces an XML validation error.
The listXML(Context,StringBuffer) method is called
recursively to handle nested contexts. The problem is
cause by grouping in a single try-catch block the code
to append tag, call self, and append
tag. When listXML throws an exception, the
closing tag is never appended to the buffer.
The fix strategy is to restructure the error handling to
minimize the amount of code contained in try block.
Here's a diff for a fix:
diff -r1.19 JNDIView.java
220a221,223
>
> Collection containers = null;
>
223,257c226
< Collection containers = (Collection)
server.getAttribute(app, "Containers");
< for (Iterator iter = containers.iterator();
iter.hasNext();)
< {
<Container con = (Container)iter.next();
</* Set the thread class loader to that of the
container as
< the class loader is used by the java:
context object
< factory to partition the container
namespaces.
<*/
<Thread.currentThread
().setContextClassLoader(con.getClassLoader());
<String bean = con.getBeanMetaData
().getEjbName();
<buffer.append( "" );
<buffer.append( '\n' );
<buffer.append
( "java:comp" );
<buffer.append( '\n' );
<buffer.append( ""
+ bean + "" );
<buffer.append( '\n' );
<try
<{
< context = new InitialContext();
< context = (Context)context.lookup
("java:comp");
<}
<catch(NamingException e)
<{
< buffer.append( "" );
< buffer.append( '\n' );
< buffer.append( "" + "Failed on
lookup, " + e.toString( true ) + "" );
< buffer.append( '\n' );
< buffer.append( "" );
< buffer.append( '\n' );
< continue;
<}
<listXML( context, buffer );
<buffer.append( "" );
<buffer.append( '\n' );
< }
---
> containers = (Collection)server.getAttribute
(app, "Containers");
261c230
< log.error("getConainers failed", e);
---
> log.error("getContainers failed", e);
266a236,286
>
> for (Iterator iter = containers.iterator();
iter.hasNext();)
> {
> Container con = (Container)iter.next();
> /* Set the thread class loader to that of the
container as
>the class loader is used by the java:
context object
>factory to partition the container
namespaces.
> */
> Thread.currentThread().setContextClassLoader
(con.getClassLoader());
> String bean = con.getBeanMetaData
().getEjbName();
> buffer.append( "" );
> buffer.append( '\n' );
> buffer.append( "java:comp" );
> buffer.append( '\n' );
> buffer.append( "" +
bean + "" );
> buffer.append( '\n' );
> try
> {
>context = new InitialContext();
>context = (Context)context.lookup
("java:comp");
>
[JBoss-dev] [ jboss-Bugs-664322 ] EJBQL Date Comparison Broken
Bugs item #664322, was opened at 2003-01-08 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Daniel Spilker (nichdiemama) Assigned to: Alexey Loubyansky (loubyansky) Summary: EJBQL Date Comparison Broken Initial Comment: When trying to find some CMP entity beans by a finder method which takes a java.util.Date as a parameter and does an equals compaision with that parameter to a cmp-field, the returned result is always empty. EJBQL: SELECT Object(r) FROM TimeRecord AS r WHERE r.date=?1 "<" and ">" work fine, I also tried different databases it's always the same problem. -- Comment By: Daniel Spilker (nichdiemama) Date: 2003-01-08 16:18 Message: Logged In: YES user_id=279538 OK, it works for me too. When constructing a test case I realized that I ran into the usual millisecond bug. Sorry for bothering you, Daniel -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 14:29 Message: Logged In: YES user_id=543482 Could you, please, provide a testcase that shows it? It works for me. alex -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664322&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664373 ] "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work
Bugs item #664373, was opened at 2003-01-08 15:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Sacha Labourey (slaboure) >Assigned to: Alexey Loubyansky (loubyansky) >Summary: "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work Initial Comment: Situation: one-to-one relationship between Customer and HomeAddress. Some Customers do have a home address (=> cust.getHomeAddress() != null) while others don't (=> cust.getHomeAddress() == null) Problem: queries such as: SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NULL or SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NOT NULL always return an empty collection. This was working under 3.0.x (maybe it still works) but it doesn't work under a fresh Branch_3_2 snapshot from this morning. -- >Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 16:29 Message: Logged In: YES user_id=543482 It could be because of Jeremy's fix for "638488: OR with IS NOT EMPTY" notExistsClause method that handles IS [NOT] EMPTY is used for IS [NOT] NULL in two cases: 1. table mapping; 2. the query is performed on the entity with CMR that has no foreign key. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664373 ] "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work
Bugs item #664373, was opened at 2003-01-08 15:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Alexey Loubyansky (loubyansky) >Summary: "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work Initial Comment: Situation: one-to-one relationship between Customer and HomeAddress. Some Customers do have a home address (=> cust.getHomeAddress() != null) while others don't (=> cust.getHomeAddress() == null) Problem: queries such as: SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NULL or SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NOT NULL always return an empty collection. This was working under 3.0.x (maybe it still works) but it doesn't work under a fresh Branch_3_2 snapshot from this morning. -- >Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 17:48 Message: Logged In: YES user_id=543482 Sacha, what database are you using? I think this is due to the subquery support in IS [NOT] EMPTY as it works for me in MySql with joining. alex -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 16:29 Message: Logged In: YES user_id=543482 It could be because of Jeremy's fix for "638488: OR with IS NOT EMPTY" notExistsClause method that handles IS [NOT] EMPTY is used for IS [NOT] NULL in two cases: 1. table mapping; 2. the query is performed on the entity with CMR that has no foreign key. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664373 ] "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work
Bugs item #664373, was opened at 2003-01-08 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: Accepted Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Alexey Loubyansky (loubyansky) >Summary: "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work Initial Comment: Situation: one-to-one relationship between Customer and HomeAddress. Some Customers do have a home address (=> cust.getHomeAddress() != null) while others don't (=> cust.getHomeAddress() == null) Problem: queries such as: SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NULL or SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NOT NULL always return an empty collection. This was working under 3.0.x (maybe it still works) but it doesn't work under a fresh Branch_3_2 snapshot from this morning. -- >Comment By: Sacha Labourey (slaboure) Date: 2003-01-08 16:54 Message: Logged In: YES user_id=95900 I am using hypersonic (embedded DB) and it was working under 3.0. If you want a testcase, you can use run example 8.2g (run.client_82g) from the O'reilly JBoss workbook: it does exactly that and was working under 3.0. See here for download: http://www.jboss.org/forums/thread.jsp? forum=152&thread=21861 -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 16:48 Message: Logged In: YES user_id=543482 Sacha, what database are you using? I think this is due to the subquery support in IS [NOT] EMPTY as it works for me in MySql with joining. alex -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 15:29 Message: Logged In: YES user_id=543482 It could be because of Jeremy's fix for "638488: OR with IS NOT EMPTY" notExistsClause method that handles IS [NOT] EMPTY is used for IS [NOT] NULL in two cases: 1. table mapping; 2. the query is performed on the entity with CMR that has no foreign key. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664459 ] JMS Message lost due to synchronization in MessageReference
Bugs item #664459, was opened at 2003-01-08 11:21
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664459&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Harris (rpharris)
Assigned to: Nobody/Anonymous (nobody)
Summary: JMS Message lost due to synchronization in MessageReference
Initial Comment:
Bug and fix submitted by Ryan Harris of Sterling
Commerce, Inc. http://www.sterlingcommerce.com
Due to a synchronization error in a MessageReference
object, the file reference to a Message object is
deleted while no hard reference exists. However, the
system is not finished processing the Message and when
it attempts to retrieve its hard reference from the
file reference on the disk, it fails with a
FileNotFound exception. A fix is included and a is
attached. It will be submitted in the patch section as
well.
The problem occurs when a series of the following three
events occurs in a MessageReference object. This
scenario only occurs when the heap size has passed the
HighMemoryMark of the Cachemanager AND the garbage
collector happens to run just after the
validateSoftReferenceDepth step below.
Original MessageReference.invalidate:
public void invalidate() throws JMSException
{
clear(); // Clear out the disk copy
}
This is the original course of events that occurs:
**
validateSoftRefernceDepth (deleting our hard reference
and creating a soft reference)
**context switch**
GC Runs and collects our hard reference.
**context switch**
invalidate and clear are called (we have no hard
reference at this point, deleting our disk reference)
**context switch**
makeHard is called (we have no hard reference nor a
file on the disk) Explosion.
In order to fix this error, it is required that we
check within
the invalidate method if we actually have a hard reference
to the object, before we blow away the file reference
on the disk.
Modified MessageReference.invalidate:
public void invalidate() throws JMSException
{
synchronized(messageCache) {
if(hardReference != null)
clear(); // Clear out the disk copy
}
}
This forces the events into the following pattern:
***
validateSoftRefernceDepth (deleting our hard reference)
**context switch**
GC Runs and collects our hard reference.
**context switch**
invalidate (fails to delete disk reference because we
have no hard reference)
**context switch**
makeHard is called (we have no hard reference but
thefile is still on the disk) Everything is happy.
Operating Systems: Linux, Windows2k, HPUX, Solaris,
AIX, Others most likely
JDK: 1.3.1
Stack Trace:
[WARN,SpyConnectionConsumer] Connection consumer
closing due to error in
listening thread.
org.jboss.mq.SpyJMSException: Could not load message
from secondary
storage: ; - nested throwable:
(java.io.FileNotFoundException:
C:\si_1230\SterlingIntegrator\jboss\jboss\tmp\jbossmq\Message-5437
(The system cannot find the file specified))
at
org.jboss.mq.pm.file.CacheStore.loadFromStorage(CacheStore.java:61)
at
org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:246)
at
org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:207)
at
org.jboss.mq.server.MessageReference.getMessage(MessageReference.java:93
)
at
org.jboss.mq.server.BasicQueue.setupMessageAcknowledgement(BasicQueue.ja
va:380)
at
org.jboss.mq.server.BasicQueue.receive(BasicQueue.java:238)
at
org.jboss.mq.server.JMSQueue.receive(JMSQueue.java:122)
at
org.jboss.mq.server.ClientConsumer.receive(ClientConsumer.java:225)
at
org.jboss.mq.server.JMSDestinationManager.receive(JMSDestinationManager.
java:669)
at
org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:4
33)
at
org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:227)
at
org.jboss.mq.il.jvm.JVMServerIL.receive(JVMServerIL.java:245)
at
org.jboss.mq.Connection.receive(Connection.java:1046)
at
org.jboss.mq.SpyConnectionConsumer.run(SpyConnectionConsumer.java:183)
at java.lang.Thread.run(Thread.java:479)
java.io.FileNotFoundException:
C:\si_1230\SterlingIntegrator\jboss\jboss\tmp\jbossmq\Message-5437
(The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at
java.io.FileInputStream.(FileInputStream.java:59)
at
java.io.FileInputStream.(FileInputStream.java:90)
at
org.jboss.mq.pm.file.CacheStore.loadFromStorage(CacheStore.java:54)
at
org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:246)
at
org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:207)
at
org.jboss.mq.server.MessageReferenc
[JBoss-dev] [ jboss-Bugs-664453 ] 3.2beta3 breaks multi-partition config
Bugs item #664453, was opened at 2003-01-08 09:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Cleveland (groovesoftware) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2beta3 breaks multi-partition config Initial Comment: The attached configuration is a slimmed down version of default with clustering added. It has been working just fine (with 3.0, 3.2beta1 and 3.2beta2) until 3.2beta3 and with 3.2beta3 it fails to start up and just hangs while initializing clustering. I am testing with 3.2beta3 with integrated tomcat 4.0.4, but I don't think the tomcat portion is involved. I am running on Solaris with JDK 1.3.1. I have also tested with the latest 3.2 from CVS and have the same problem there. The steps to reproduce are: 1. Clean installation of jboss 3.2beta3 with tomcat 4.0.4 2. unzip the attached zip file in the server directory 3. Start up the configuration prod-ejb1 4. Attempt to start up the configuration prod-ejb2 on the same machine. The startup will hang during cluster initialization. This bug is really hurting our progress and I am hoping it can be fixed in 3.2RC1. Thanks, Matt Cleveland -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-664469 ] JMS Message lost due to synchronization in MessageReference
Patches item #664469, was opened at 2003-01-08 11:36
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=664469&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Harris (rpharris)
Assigned to: Nobody/Anonymous (nobody)
Summary: JMS Message lost due to synchronization in MessageReference
Initial Comment:
References Bug#664459
Bug and fix submitted by Ryan Harris of Sterling
Commerce, Inc. http://www.sterlingcommerce.com
Due to a synchronization error in a
MessageReference
object, the file reference to a Message object is
deleted while no hard reference exists. However, the
system is not finished processing the Message and
when
it attempts to retrieve its hard reference from the
file reference on the disk, it fails with a
FileNotFound exception. A fix is included and a is
attached. It will be submitted in the patch section as
well.
The problem occurs when a series of the following
three
events occurs in a MessageReference object. This
scenario only occurs when the heap size has passed
the
HighMemoryMark of the Cachemanager AND the
garbage
collector happens to run just after the
validateSoftReferenceDepth step below.
Original MessageReference.invalidate:
public void invalidate() throws JMSException
{
clear(); // Clear out the disk copy
}
This is the original course of events that occurs:
**
validateSoftRefernceDepth (deleting our hard
reference
and creating a soft reference)
**context switch**
GC Runs and collects our hard reference.
**context switch**
invalidate and clear are called (we have no hard
reference at this point, deleting our disk reference)
**context switch**
makeHard is called (we have no hard reference nor a
file on the disk) Explosion.
In order to fix this error, it is required that we
check within
the invalidate method if we actually have a hard
reference
to the object, before we blow away the file reference
on the disk.
Modified MessageReference.invalidate:
public void invalidate() throws JMSException
{
synchronized(messageCache) {
if(hardReference != null)
clear(); // Clear out the disk copy
}
}
This forces the events into the following pattern:
***
validateSoftRefernceDepth (deleting our hard
reference)
**context switch**
GC Runs and collects our hard reference.
**context switch**
invalidate (fails to delete disk reference because we
have no hard reference)
**context switch**
makeHard is called (we have no hard reference but
thefile is still on the disk) Everything is happy.
Operating Systems: Linux, Windows2k, HPUX, Solaris,
AIX, Others most likely
JDK: 1.3.1
Stack Trace:
[WARN,SpyConnectionConsumer] Connection
consumer
closing due to error in
listening thread.
org.jboss.mq.SpyJMSException: Could not load
message
from secondary
storage: ; - nested throwable:
(java.io.FileNotFoundException:
C:\si_1230
\SterlingIntegrator\jboss\jboss\tmp\jbossmq\Message
-5437
(The system cannot find the file specified))
at
org.jboss.mq.pm.file.CacheStore.loadFromStorage
(CacheStore.java:61)
at
org.jboss.mq.server.MessageCache.loadFromStorage
(MessageCache.java:246)
at
org.jboss.mq.server.MessageReference.makeHard
(MessageReference.java:207)
at
org.jboss.mq.server.MessageReference.getMessage
(MessageReference.java:93
)
at
org.jboss.mq.server.BasicQueue.setupMessageAckn
owledgement(BasicQueue.ja
va:380)
at
org.jboss.mq.server.BasicQueue.receive
(BasicQueue.java:238)
at
org.jboss.mq.server.JMSQueue.receive
(JMSQueue.java:122)
at
org.jboss.mq.server.ClientConsumer.receive
(ClientConsumer.java:225)
at
org.jboss.mq.server.JMSDestinationManager.receive
(JMSDestinationManager.
java:669)
at
org.jboss.mq.server.TracingInterceptor.receive
(TracingInterceptor.java:4
33)
at
org.jboss.mq.server.JMSServerInvoker.receive
(JMSServerInvoker.java:227)
at
org.jboss.mq.il.jvm.JVMServerIL.receive
(JVMServerIL.java:245)
at
org.jboss.mq.Connection.receive
(Connection.java:1046)
at
org.jboss.mq.SpyConnectionConsumer.run
(SpyConnectionConsumer.java:183)
at java.lang.Thread.run(Thread.java:479)
java.io.FileNotFoundException:
C:\si_1230
\SterlingIntegrator\jboss\jboss\tmp\jbossmq\Message
-5437
(The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at
java.io.FileInputStream.
(FileInputStream.java:59)
at
java.io.FileInputStream.
(FileInputStream.java:90)
at
org.jboss.mq.pm.file.CacheStore.loadFromStorage
(CacheStore.java:54)
at
org.jboss.mq.server.MessageCache.loadFromStorage
(MessageCache.java:246)
at
org.jboss.mq.server.MessageReference.makeHard
(MessageReference.java:207)
at
org.jboss.mq.server.MessageReference.getMessage
(MessageReference.java:93
)
at
org.jboss.mq.server.BasicQueue.setupMessageAckn
owledgement(BasicQueue.ja
va:380)
at
org.jboss.mq.server.BasicQueue.receive
(BasicQueue.
[JBoss-dev] [ jboss-Bugs-664459 ] JMS Message lost due to synchronization in MessageReference
Bugs item #664459, was opened at 2003-01-08 16:21
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664459&group_id=22866
Category: JBossMQ
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Ryan Harris (rpharris)
Assigned to: Nobody/Anonymous (nobody)
Summary: JMS Message lost due to synchronization in MessageReference
Initial Comment:
Bug and fix submitted by Ryan Harris of Sterling
Commerce, Inc. http://www.sterlingcommerce.com
Due to a synchronization error in a MessageReference
object, the file reference to a Message object is
deleted while no hard reference exists. However, the
system is not finished processing the Message and when
it attempts to retrieve its hard reference from the
file reference on the disk, it fails with a
FileNotFound exception. A fix is included and a is
attached. It will be submitted in the patch section as
well.
The problem occurs when a series of the following three
events occurs in a MessageReference object. This
scenario only occurs when the heap size has passed the
HighMemoryMark of the Cachemanager AND the garbage
collector happens to run just after the
validateSoftReferenceDepth step below.
Original MessageReference.invalidate:
public void invalidate() throws JMSException
{
clear(); // Clear out the disk copy
}
This is the original course of events that occurs:
**
validateSoftRefernceDepth (deleting our hard reference
and creating a soft reference)
**context switch**
GC Runs and collects our hard reference.
**context switch**
invalidate and clear are called (we have no hard
reference at this point, deleting our disk reference)
**context switch**
makeHard is called (we have no hard reference nor a
file on the disk) Explosion.
In order to fix this error, it is required that we
check within
the invalidate method if we actually have a hard reference
to the object, before we blow away the file reference
on the disk.
Modified MessageReference.invalidate:
public void invalidate() throws JMSException
{
synchronized(messageCache) {
if(hardReference != null)
clear(); // Clear out the disk copy
}
}
This forces the events into the following pattern:
***
validateSoftRefernceDepth (deleting our hard reference)
**context switch**
GC Runs and collects our hard reference.
**context switch**
invalidate (fails to delete disk reference because we
have no hard reference)
**context switch**
makeHard is called (we have no hard reference but
thefile is still on the disk) Everything is happy.
Operating Systems: Linux, Windows2k, HPUX, Solaris,
AIX, Others most likely
JDK: 1.3.1
Stack Trace:
[WARN,SpyConnectionConsumer] Connection consumer
closing due to error in
listening thread.
org.jboss.mq.SpyJMSException: Could not load message
from secondary
storage: ; - nested throwable:
(java.io.FileNotFoundException:
C:\si_1230\SterlingIntegrator\jboss\jboss\tmp\jbossmq\Message-5437
(The system cannot find the file specified))
at
org.jboss.mq.pm.file.CacheStore.loadFromStorage(CacheStore.java:61)
at
org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:246)
at
org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:207)
at
org.jboss.mq.server.MessageReference.getMessage(MessageReference.java:93
)
at
org.jboss.mq.server.BasicQueue.setupMessageAcknowledgement(BasicQueue.ja
va:380)
at
org.jboss.mq.server.BasicQueue.receive(BasicQueue.java:238)
at
org.jboss.mq.server.JMSQueue.receive(JMSQueue.java:122)
at
org.jboss.mq.server.ClientConsumer.receive(ClientConsumer.java:225)
at
org.jboss.mq.server.JMSDestinationManager.receive(JMSDestinationManager.
java:669)
at
org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:4
33)
at
org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:227)
at
org.jboss.mq.il.jvm.JVMServerIL.receive(JVMServerIL.java:245)
at
org.jboss.mq.Connection.receive(Connection.java:1046)
at
org.jboss.mq.SpyConnectionConsumer.run(SpyConnectionConsumer.java:183)
at java.lang.Thread.run(Thread.java:479)
java.io.FileNotFoundException:
C:\si_1230\SterlingIntegrator\jboss\jboss\tmp\jbossmq\Message-5437
(The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at
java.io.FileInputStream.(FileInputStream.java:59)
at
java.io.FileInputStream.(FileInputStream.java:90)
at
org.jboss.mq.pm.file.CacheStore.loadFromStorage(CacheStore.java:54)
at
org.jboss.mq.server.MessageCache.loadFromStorage(MessageCache.java:246)
at
org.jboss.mq.server.MessageReference.makeHard(MessageReference.java:207)
at
org.jboss.mq.server.MessageReferenc
[JBoss-dev] [ jboss-Bugs-664453 ] 3.2beta3 breaks multi-partition config
Bugs item #664453, was opened at 2003-01-08 09:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Cleveland (groovesoftware) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2beta3 breaks multi-partition config Initial Comment: The attached configuration is a slimmed down version of default with clustering added. It has been working just fine (with 3.0, 3.2beta1 and 3.2beta2) until 3.2beta3 and with 3.2beta3 it fails to start up and just hangs while initializing clustering. I am testing with 3.2beta3 with integrated tomcat 4.0.4, but I don't think the tomcat portion is involved. I am running on Solaris with JDK 1.3.1. I have also tested with the latest 3.2 from CVS and have the same problem there. The steps to reproduce are: 1. Clean installation of jboss 3.2beta3 with tomcat 4.0.4 2. unzip the attached zip file in the server directory 3. Start up the configuration prod-ejb1 4. Attempt to start up the configuration prod-ejb2 on the same machine. The startup will hang during cluster initialization. This bug is really hurting our progress and I am hoping it can be fixed in 3.2RC1. Thanks, Matt Cleveland -- >Comment By: Matt Cleveland (groovesoftware) Date: 2003-01-08 10:31 Message: Logged In: YES user_id=85088 I had to reduce the file size so it would attach, so please use the following steps to reproduce. 1. Make a copy of the default configuration named prod-ejb1 2. Make another copy of the default configuration named prod-ejb2 3. Copy the javagroups jar from the all configuration into the prod-ejb1 and prod-ejb2 configurations. 4. Unzip the attached jar in the server directory 5. Start up the configuration prod-ejb1 6. Attempt to start up the configuration prod-ejb2. The startup will hang during cluster initialization. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664373 ] "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work
Bugs item #664373, was opened at 2003-01-08 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 Category: JBossCMP Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Alexey Loubyansky (loubyansky) >Summary: "WHERE xxx IS NULL" EQL with 1-1 relationship doesn't work Initial Comment: Situation: one-to-one relationship between Customer and HomeAddress. Some Customers do have a home address (=> cust.getHomeAddress() != null) while others don't (=> cust.getHomeAddress() == null) Problem: queries such as: SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NULL or SELECT OBJECT ( c ) FROM Customer c WHERE c.homeAddress IS NOT NULL always return an empty collection. This was working under 3.0.x (maybe it still works) but it doesn't work under a fresh Branch_3_2 snapshot from this morning. -- >Comment By: Sacha Labourey (slaboure) Date: 2003-01-08 19:43 Message: Logged In: YES user_id=95900 Alexey's recent commit fixes the bug -- Comment By: Sacha Labourey (slaboure) Date: 2003-01-08 16:54 Message: Logged In: YES user_id=95900 I am using hypersonic (embedded DB) and it was working under 3.0. If you want a testcase, you can use run example 8.2g (run.client_82g) from the O'reilly JBoss workbook: it does exactly that and was working under 3.0. See here for download: http://www.jboss.org/forums/thread.jsp? forum=152&thread=21861 -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 16:48 Message: Logged In: YES user_id=543482 Sacha, what database are you using? I think this is due to the subquery support in IS [NOT] EMPTY as it works for me in MySql with joining. alex -- Comment By: Alexey Loubyansky (loubyansky) Date: 2003-01-08 15:29 Message: Logged In: YES user_id=543482 It could be because of Jeremy's fix for "638488: OR with IS NOT EMPTY" notExistsClause method that handles IS [NOT] EMPTY is used for IS [NOT] NULL in two cases: 1. table mapping; 2. the query is performed on the entity with CMR that has no foreign key. ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664373&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Nobody/Anonymous (nobody) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Nobody/Anonymous (nobody) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Paul Morris (rpmorris) Date: 2003-01-08 15:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Nobody/Anonymous (nobody) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Paul Morris (rpmorris) Date: 2003-01-08 15:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 15:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.) ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664453 ] 3.2beta3 breaks multi-partition config
Bugs item #664453, was opened at 2003-01-08 17:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 Category: Clustering Group: v3.2 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Matt Cleveland (groovesoftware) >Assigned to: Sacha Labourey (slaboure) Summary: 3.2beta3 breaks multi-partition config Initial Comment: The attached configuration is a slimmed down version of default with clustering added. It has been working just fine (with 3.0, 3.2beta1 and 3.2beta2) until 3.2beta3 and with 3.2beta3 it fails to start up and just hangs while initializing clustering. I am testing with 3.2beta3 with integrated tomcat 4.0.4, but I don't think the tomcat portion is involved. I am running on Solaris with JDK 1.3.1. I have also tested with the latest 3.2 from CVS and have the same problem there. The steps to reproduce are: 1. Clean installation of jboss 3.2beta3 with tomcat 4.0.4 2. unzip the attached zip file in the server directory 3. Start up the configuration prod-ejb1 4. Attempt to start up the configuration prod-ejb2 on the same machine. The startup will hang during cluster initialization. This bug is really hurting our progress and I am hoping it can be fixed in 3.2RC1. Thanks, Matt Cleveland -- >Comment By: Sacha Labourey (slaboure) Date: 2003-01-08 22:06 Message: Logged In: YES user_id=95900 This comes from the current version of JG in JBoss. The problem has been fixed in JG. A new version of JG will be incoroporated before 3.0.5, tomorrow I hope. -- Comment By: Matt Cleveland (groovesoftware) Date: 2003-01-08 18:31 Message: Logged In: YES user_id=85088 I had to reduce the file size so it would attach, so please use the following steps to reproduce. 1. Make a copy of the default configuration named prod-ejb1 2. Make another copy of the default configuration named prod-ejb2 3. Copy the javagroups jar from the all configuration into the prod-ejb1 and prod-ejb2 configurations. 4. Unzip the attached jar in the server directory 5. Start up the configuration prod-ejb1 6. Attempt to start up the configuration prod-ejb2. The startup will hang during cluster initialization. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None >Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) >Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Scott M Stark (starksm) Date: 2003-01-08 13:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 12:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 12:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.) ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 13:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 18:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 17:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 17:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 13:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664453 ] 3.2beta3 breaks multi-partition config
Bugs item #664453, was opened at 2003-01-08 17:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 Category: Clustering Group: v3.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matt Cleveland (groovesoftware) >Assigned to: Nobody/Anonymous (nobody) Summary: 3.2beta3 breaks multi-partition config Initial Comment: The attached configuration is a slimmed down version of default with clustering added. It has been working just fine (with 3.0, 3.2beta1 and 3.2beta2) until 3.2beta3 and with 3.2beta3 it fails to start up and just hangs while initializing clustering. I am testing with 3.2beta3 with integrated tomcat 4.0.4, but I don't think the tomcat portion is involved. I am running on Solaris with JDK 1.3.1. I have also tested with the latest 3.2 from CVS and have the same problem there. The steps to reproduce are: 1. Clean installation of jboss 3.2beta3 with tomcat 4.0.4 2. unzip the attached zip file in the server directory 3. Start up the configuration prod-ejb1 4. Attempt to start up the configuration prod-ejb2 on the same machine. The startup will hang during cluster initialization. This bug is really hurting our progress and I am hoping it can be fixed in 3.2RC1. Thanks, Matt Cleveland -- >Comment By: Sacha Labourey (slaboure) Date: 2003-01-09 10:04 Message: Logged In: YES user_id=95900 New JG release has been commited to HEAD, Branch_3_2 and Branch_3_0. -- Comment By: Sacha Labourey (slaboure) Date: 2003-01-08 22:06 Message: Logged In: YES user_id=95900 This comes from the current version of JG in JBoss. The problem has been fixed in JG. A new version of JG will be incoroporated before 3.0.5, tomorrow I hope. -- Comment By: Matt Cleveland (groovesoftware) Date: 2003-01-08 18:31 Message: Logged In: YES user_id=85088 I had to reduce the file size so it would attach, so please use the following steps to reproduce. 1. Make a copy of the default configuration named prod-ejb1 2. Make another copy of the default configuration named prod-ejb2 3. Copy the javagroups jar from the all configuration into the prod-ejb1 and prod-ejb2 configurations. 4. Unzip the attached jar in the server directory 5. Start up the configuration prod-ejb1 6. Attempt to start up the configuration prod-ejb2. The startup will hang during cluster initialization. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664453&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665008 ] cache lists
Bugs item #665008, was opened at 2003-01-09 13:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665008&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Markus Menner (morphace) Assigned to: Nobody/Anonymous (nobody) Summary: cache lists Initial Comment: Hi, apparently cache-lists are not cleared correctly. In my case I used JB3.2b3 but it is the same with 3.0.4. My OS: WinXP, JDK 1.4.1_01 Yes, I have the CMP docs ... ;-) Here my standardjbosscmp-jdbc.xml settings: on-find 500 * 1000 I use commit-option B, instance per transaction configuration for my CMP EJB's. When you execute a finder (in my case a dynamic EJB-QL finder) JBossCMP uses the read-ahead mechanism to optimize loading. So far, so good. For example three entites A, B and C. A's relationship to B is (A) 1-n (B) with a foreign-key. B's relationship to C is (B) n-1 (C) with a foreign-key. The B entities are read-ahead correctly. Now, the second case: Three entites D, E and B. D's relationship to E is (D) 1-n (E) with a foreign-key. B's relationship to E is (E) n-1 (B) with a foreign-key. When you execute a finder on D the cache-lists from the first finder execution are used! I noticed, that read-ahead is only working for 1-n relationships :-(, not for n-1 (is it a bug ? Anyway, I'll submit it). So normally you should get a query for each B, which is the case if you do not execute the first query, but if you do it, the B's are read-ahead corresponding to the cache-lists of the first query!? I hope that I explained everything enough. TX Markus ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665008&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665013 ] Read ahead
Bugs item #665013, was opened at 2003-01-09 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665013&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Markus Menner (morphace) Assigned to: Nobody/Anonymous (nobody) Summary: Read ahead Initial Comment: Hi, apparently read-ahead is only working for 1-n relationships :-(, not for n-1. In my case I used JB3.2b3 but it is the same with 3.0.4. My OS: WinXP, JDK 1.4.1_01 Yes, I have the CMP docs ... ;-) Here my standardjbosscmp-jdbc.xml settings: on-find 500 * 1000 I use commit-option B, instance per transaction configuration for my CMP EJB's. I looked at the code, and (I hope that I am right) it's clear that it does not work, because the read-ahead mechanism relies on the collection of primary keys (not foreign keys). I feel, that it could be (easily ;-)) done by collecting the foreign keys too and due to the fact that the current behavior has grave performance loss I submit it as bug. Is it okay ? TX Markus -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665013&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665013 ] Read ahead
Bugs item #665013, was opened at 2003-01-09 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665013&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None >Priority: 8 Submitted By: Markus Menner (morphace) Assigned to: Nobody/Anonymous (nobody) Summary: Read ahead Initial Comment: Hi, apparently read-ahead is only working for 1-n relationships :-(, not for n-1. In my case I used JB3.2b3 but it is the same with 3.0.4. My OS: WinXP, JDK 1.4.1_01 Yes, I have the CMP docs ... ;-) Here my standardjbosscmp-jdbc.xml settings: on-find 500 * 1000 I use commit-option B, instance per transaction configuration for my CMP EJB's. I looked at the code, and (I hope that I am right) it's clear that it does not work, because the read-ahead mechanism relies on the collection of primary keys (not foreign keys). I feel, that it could be (easily ;-)) done by collecting the foreign keys too and due to the fact that the current behavior has grave performance loss I submit it as bug. Is it okay ? TX Markus -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665013&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4
Bugs item #665037, was opened at 2003-01-09 14:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
Category: JBossServer
Group: v4.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4
Initial Comment:
When running our remote clients we get a
NoInitialContextException. The exception is caused by
a call to HomeHandle.getEJBHome(). After Looking
through the source code for JBOSS, it seems that
JBOSS 3.0.4's
com.jboss.proxy.ejb.handle.HomeHandleImpl does not
serialize the JNDI context information like is should (and
used to in JBOSS2.4. Instead it always creates a new
InitialContext in the getEJBHome method. The following
example illustrates the problem.
import
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;
public class Example {
public static void main(String[] args) throws Exception
{
Properties _prop = new Properties();
_prop.setProperty
("java.naming.factory.initial","org.jnp.interfaces.NamingC
ontextFactory");
_prop.setProperty
("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.
interfaces");
_prop.setProperty
("java.naming.provider.url","localhost");
_prop.setProperty
("java.naming.provider.port","1099");
InitialContext _ic = new InitialContext(_prop);
POFObjectManagerRemoteHome _om_home =
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
("qlink/POFObjectManager"),POFObjectManagerRemote
Home.class);
HomeHandle _hhandle = _om_home.getHomeHandle
();
//Here is where the NoInitialContextException is
thrown
_om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
}
}
Thanks,
Shone Sadler
Senior Software Developer
Q-Link Technologies
OS: Win2000
JDK:1.3.1_06
Server Trace:
C:\development>java Example
Exception in thread "main" java.rmi.ServerException:
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to
specify class name in e
vironment or system property, or as an applet
parameter, or in an application r
source file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify
class name in environme
t or system property, or as an applet parameter, or in an
application resource
ile: java.naming.factory.initial
at
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665037 ] HomeHandle causing NoInitialContextException in JBOSS3.0.4
Bugs item #665037, was opened at 2003-01-09 14:32
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
Category: JBossServer
>Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Shone Sadler (ssadler)
Assigned to: Nobody/Anonymous (nobody)
Summary: HomeHandle causing NoInitialContextException in JBOSS3.0.4
Initial Comment:
When running our remote clients we get a
NoInitialContextException. The exception is caused by
a call to HomeHandle.getEJBHome(). After Looking
through the source code for JBOSS, it seems that
JBOSS 3.0.4's
com.jboss.proxy.ejb.handle.HomeHandleImpl does not
serialize the JNDI context information like is should (and
used to in JBOSS2.4. Instead it always creates a new
InitialContext in the getEJBHome method. The following
example illustrates the problem.
import
com.qlinktech.pof3.omapi.POFObjectManagerRemoteHo
me;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
import javax.ejb.HomeHandle;
import java.util.Properties;
public class Example {
public static void main(String[] args) throws Exception
{
Properties _prop = new Properties();
_prop.setProperty
("java.naming.factory.initial","org.jnp.interfaces.NamingC
ontextFactory");
_prop.setProperty
("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.
interfaces");
_prop.setProperty
("java.naming.provider.url","localhost");
_prop.setProperty
("java.naming.provider.port","1099");
InitialContext _ic = new InitialContext(_prop);
POFObjectManagerRemoteHome _om_home =
(POFObjectManagerRemoteHome)
PortableRemoteObject.narrow(_ic.lookup
("qlink/POFObjectManager"),POFObjectManagerRemote
Home.class);
HomeHandle _hhandle = _om_home.getHomeHandle
();
//Here is where the NoInitialContextException is
thrown
_om_home = (POFObjectManagerRemoteHome)
javax.rmi.PortableRemoteObject.narrow
(_hhandle.getEJBHome
(),POFObjectManagerRemoteHome.class);
}
}
Thanks,
Shone Sadler
Senior Software Developer
Q-Link Technologies
OS: Win2000
JDK:1.3.1_06
Server Trace:
C:\development>java Example
Exception in thread "main" java.rmi.ServerException:
Could not get EJBHome; nes
ed exception is:
javax.naming.NoInitialContextException: Need to
specify class name in e
vironment or system property, or as an applet
parameter, or in an application r
source file: java.naming.factory.initial
javax.naming.NoInitialContextException: Need to specify
class name in environme
t or system property, or as an applet parameter, or in an
application resource
ile: java.naming.factory.initial
at
javax.naming.spi.NamingManager.getInitialContext
(NamingManager.java:
38)
at javax.naming.InitialContext.getDefaultInitCtx
(InitialContext.java:24
)
at
javax.naming.InitialContext.getURLOrDefaultInitCtx
(InitialContext.ja
a:278)
at javax.naming.InitialContext.lookup
(InitialContext.java:345)
at
org.jboss.proxy.ejb.handle.HomeHandleImpl.getEJBHom
e(HomeHandleImpl.
ava:72)
at Example.main(Example.java:29)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665037&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665067 ] Managed Connection equals Null! Problems in JBOSS 3.0.3
Bugs item #665067, was opened at 2003-01-09 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665067&group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Michael Ukpong (michaelukpong) Assigned to: Nobody/Anonymous (nobody) Summary: Managed Connection equals Null! Problems in JBOSS 3.0.3 Initial Comment: The .remove() method of some Entity beans I wrote and deployed in JBoss 3.0.0 is now throwing a "Managed Connection = null" exception in Jboss 3.0.3. I earlier noticed that these entities gave a "you are not getting the semantics you expect" warning (both in Jboss 3.0.0 and 3.0.3) but I ignored this warning in Jboss 3.0.0. Could this be the cause of the exception now thrown in Jboss 3.0.3? The funny thing is that if you keep looping on the remove (), where the number of iterations is the record length of the underlying table + 1, it eventually works! So its like the managed connection is restored after a certain number of failed attempts. What could this mean? Note that this remove() method is NOT called directly from a servlet, but through a stateless session bean. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665067&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665192 ] links broken on the projects page
Bugs item #665192, was opened at 2003-01-09 13:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665192&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Munz (mattmunz) Assigned to: Nobody/Anonymous (nobody) Summary: links broken on the projects page Initial Comment: I couldn't find a "website" category for this, so I just set the category to "none". The following page has several broken links. http://jboss.org/developers/projects/jboss/projects.php - Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665192&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665360 ] MDB pool size is not bounded -- Is the max size being read?
Bugs item #665360, was opened at 2003-01-09 14:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665360&group_id=22866 Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Elias Ross (genman) Assigned to: Nobody/Anonymous (nobody) Summary: MDB pool size is not bounded -- Is the max size being read? Initial Comment: I don't really want to create 100 MDB for my application, so I changed the standardjboss.xml configuration (like I did in 3.2): --- standardjboss.xml Fri Dec 20 18:47:58 2002 +++ /home/eross/src/javapackages/jboss/server/default/conf/standardjboss.xml Thu Jan 9 14:22:38 2003 @@ -774,7 +774,7 @@ org.jboss.tm.TxManager -100 + 5 This doesn't seem to work and I end up with hundreds of threads (and eventually run out of sockets...) Actually setting this number to -1 or something else doesn't create any error... I end up with this in the logs: 2003-01-09 22:32:54,997 ERROR [JMSContainerInvoker] Exception in JMSCI message listener javax.ejb.TransactionRolledbackLocalException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused); CausedByException is: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:311) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:697) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:985) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:601) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:415) at org.jboss.mq.SpySession.run(SpySession.java:293) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:536) javax.ejb.EJBException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665360&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665394 ] MDB pool size is not bounded -- Is the max size being read?
Bugs item #665394, was opened at 2003-01-09 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665394&group_id=22866 Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Elias Ross (genman) Assigned to: Nobody/Anonymous (nobody) Summary: MDB pool size is not bounded -- Is the max size being read? Initial Comment: I don't really want to create 100 MDB for my application, so I changed the standardjboss.xml configuration (like I did in 3.2): --- standardjboss.xml Fri Dec 20 18:47:58 2002 +++ /home/eross/src/javapackages/jboss/server/default/conf/standardjboss.xml Thu Jan 9 14:22:38 2003 @@ -774,7 +774,7 @@ org.jboss.tm.TxManager -100 + 5 This doesn't seem to work and I end up with hundreds of threads (and eventually run out of sockets...) Actually setting this number to -1 or something else doesn't create any error... I end up with this in the logs: 2003-01-09 22:32:54,997 ERROR [JMSContainerInvoker] Exception in JMSCI message listener javax.ejb.TransactionRolledbackLocalException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused); CausedByException is: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:311) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:697) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:985) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:601) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:415) at org.jboss.mq.SpySession.run(SpySession.java:293) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:536) javax.ejb.EJBException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) -- >Comment By: Elias Ross (genman) Date: 2003-01-09 18:38 Message: Logged In: YES user_id=556458 In my application, I create a JMS connection in my ejbCreate() method. Apparently, this is where things start to get out of control... It appears to be a configuration error (*grin*) with how the JMS connection pool is larger than the MDB pool. (I was configuring things like I did in JBoss 3.0 to reduce the pool size.) If the MDB pool is too small, then new instances are always thrown away. This is a user area, but hard to diagnose. In such situations, I notice that ejbRemove() is never called for my MDB, even though there are literally hundreds of new instances apparently thrown out. I guess I'd like someone to verify that ejbRemove is eventually called for a MDB that's thrown out of the AbstractPool... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665394&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Paul Morris (rpmorris) Date: 2003-01-10 11:18 Message: Logged In: YES user_id=683772 Of course, you're right Scott. I didn't provide nearly enough information. My first hunch was that this is a JVM problem so I switch from the Sun to the IBM JVM. It occurs with both the Sun and the IBM JVM (versions 1.4). Perhaps they share some common code, I don't know. I checked the Sun and IBM sites and no such bug has been reported for either JVM.That said, I'll will right a test case, as Scott suggested. In the meantime, here are more details of what my JBoss app is doing. I have a stateful session bean which opens a temporary file during its processing. The stream is declared transient. The stream is closed on passivate and reopened on activate. At the end of the bean's life the stream is closed and the temp file is deleted. The code releases it reference to the File instance, so it can be garbage collected. The file handles to the deleted files just don't go away (according to the lsof command output). Every thread in the process has a handle to every deleted file. I don't know if this helps, at this point. I'll report back with the results of the JVM test you suggested. -- Comment By: Scott M Stark (starksm) Date: 2003-01-08 16:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 15:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 15:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.) ------ You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663934 ] IllegalStateException in AbstractInstanceCache
Bugs item #663934, was opened at 2003-01-07 19:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663934&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Reich (sreich) >Assigned to: Adrian Brock (ejort) Summary: IllegalStateException in AbstractInstanceCache Initial Comment: When I run ECperf with a txrate of 20 on Jboss 3.0.RC2, the following exception pops up every once in a while: 18:55:19,504 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = 1041562119833 at org.jboss.ejb.plugins.AbstractInstanceCache.insert(AbstractInstanceCache.java:222) at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.createSession(StatefulSessionFilePersistenceManager.java:199) at org.jboss.ejb.StatefulSessionContainer.createHome(StatefulSessionContainer.java:441) at sun.reflect.GeneratedMethodAccessor208.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invokeHome(StatefulSessionContainer.java:763) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:105) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionInstanceInterceptor.java:128) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:62) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:129) at org.jboss.ejb.StatefulSessionContainer.invokeHome(StatefulSessionContainer.java:368) at org.jboss.ejb.Container.invoke(Container.java:730) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:554) -- >Comment By: Adrian Brock (ejort) Date: 2003-01-10 16:43 Message: Logged In: YES user_id=9459 Can you try this again with latest CVS. It should be fixed now. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663934&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665870 ] Memory Leak...somewhere...
Bugs item #665870, was opened at 2003-01-10 11:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665870&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: Memory Leak...somewhere... Initial Comment: JBoss3.0.5 RC1 I do a lot of hot deployments. I'm in the final stages of my project and am making a lot of little minor changes to the html and webapp in tons of different areas so i'm doing 150-200 deployments per day. My ear contains 2 wars a bunch of support jars and an ejb jar with 40-50 beans, entity, statelesssession, mdbs and one sar. I leave jboss running all the time, with the amount of deployments i'm doing JBoss gets an OutOfMemoryError about once a day. I have not changed the default memory setting. I guess the problem could be anywhere in jboss because i hit many, many areas...but it seams to be brought out by the number of deployments i do. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665870&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 20:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- Comment By: Michael Kloster (mikekloster) Date: 2003-01-10 19:03 Message: Logged In: YES user_id=685435 Scott M Stark, You wrote: "If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that." I have a a sample web application that can reproduce this problem (over time). The application consists only of JSP pages and images and has no dynamic content (unless you count the use of server side jsp includes). If I can show that this web application runs fine under Tomcat 4.x alone or JBoss 2.4, but does have the cause the submitters problem in JBoss 3.0.x will that satify your above stated requirement that this must be shown, in fact, to be a JBoss issue? If so, I will take the time to create and document this senario for you. thank you for your time and effort. Jboss is a wonderful product! Michael Kloster -- Comment By: Paul Morris (rpmorris) Date: 2003-01-10 16:18 Message: Logged In: YES user_id=683772 Of course, you're right Scott. I didn't provide nearly enough information. My first hunch was that this is a JVM problem so I switch from the Sun to the IBM JVM. It occurs with both the Sun and the IBM JVM (versions 1.4). Perhaps they share some common code, I don't know. I checked the Sun and IBM sites and no such bug has been reported for either JVM.That said, I'll will right a test case, as Scott suggested. In the meantime, here are more details of what my JBoss app is doing. I have a stateful session bean which opens a temporary file during its processing. The stream is declared transient. The stream is closed on passivate and reopened on activate. At the end of the bean's life the stream is closed and the temp file is deleted. The code releases it reference to the File instance, so it can be garbage collected. The file handles to the deleted files just don't go away (according to the lsof command output). Every thread in the process has a handle to every deleted file. I don't know if this helps, at this point. I'll report back with the results of the JVM test you suggested. -- Comment By: Scott M Stark (starksm) Date: 2003-01-08 21:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 20:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 20:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They contain output from the lsof command during the operation of our jboss app (start, mid, and late, respectively.) ------ You can respond by visiting: https://sourceforge.net/tracker/?fun
[JBoss-dev] [ jboss-Bugs-664635 ] Too many open files causes JBoss 3.0 to crash
Bugs item #664635, was opened at 2003-01-08 12:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664635&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Morris (rpmorris) Assigned to: Scott M Stark (starksm) Summary: Too many open files causes JBoss 3.0 to crash Initial Comment: OS: Linux 7.1 JDK: Occurs with Sun j2SDK 1.4.0 and IBM Java2 1.4 Occurs on JBoss v 3.0.0 & 3.0.4 The JVM process ends with the message "too many open files". It can be recreated simply by opening and closing files for a long enough period of time . Once a file handle is allocated it doesn't appear to go away. I've attached the console output as requestd in the bug report instructions. I have captured the output from the lsof command showing system file handles at various stages of my JBoss app operation. This output indicates that file handles don't go way even when the files are closed or deleted. I can send this lsof output to whoever investigates this problem (the web form only allows one file to be attached to the bug report). A number of developers have reported similar problems in the forum. For an example see http://www.jboss.org/forums/thread.jsp? forum=61&thread=24687 -- >Comment By: Scott M Stark (starksm) Date: 2003-01-10 11:31 Message: Logged In: YES user_id=175228 That should be fine. -- Comment By: Michael Kloster (mikekloster) Date: 2003-01-10 11:03 Message: Logged In: YES user_id=685435 Scott M Stark, You wrote: "If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that." I have a a sample web application that can reproduce this problem (over time). The application consists only of JSP pages and images and has no dynamic content (unless you count the use of server side jsp includes). If I can show that this web application runs fine under Tomcat 4.x alone or JBoss 2.4, but does have the cause the submitters problem in JBoss 3.0.x will that satify your above stated requirement that this must be shown, in fact, to be a JBoss issue? If so, I will take the time to create and document this senario for you. thank you for your time and effort. Jboss is a wonderful product! Michael Kloster -- Comment By: Paul Morris (rpmorris) Date: 2003-01-10 08:18 Message: Logged In: YES user_id=683772 Of course, you're right Scott. I didn't provide nearly enough information. My first hunch was that this is a JVM problem so I switch from the Sun to the IBM JVM. It occurs with both the Sun and the IBM JVM (versions 1.4). Perhaps they share some common code, I don't know. I checked the Sun and IBM sites and no such bug has been reported for either JVM.That said, I'll will right a test case, as Scott suggested. In the meantime, here are more details of what my JBoss app is doing. I have a stateful session bean which opens a temporary file during its processing. The stream is declared transient. The stream is closed on passivate and reopened on activate. At the end of the bean's life the stream is closed and the temp file is deleted. The code releases it reference to the File instance, so it can be garbage collected. The file handles to the deleted files just don't go away (according to the lsof command output). Every thread in the process has a handle to every deleted file. I don't know if this helps, at this point. I'll report back with the results of the JVM test you suggested. -- Comment By: Scott M Stark (starksm) Date: 2003-01-08 13:16 Message: Logged In: YES user_id=175228 How is the fact that opening and closing files files still leaves the descriptor open a JBoss problem? We don't do anything to intercept filesystem calls so the issue seems VM related. If you have a sample program that runs in a standalone VM fine, but fails when deployed to JBoss using the same VM then submit that. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 12:46 Message: Logged In: YES user_id=683772 The lsof out files mentioned in the previous comment are too large to upload to sourceforge. They are 1, 4, & 8 MBs. -- Comment By: Paul Morris (rpmorris) Date: 2003-01-08 12:42 Message: Logged In: YES user_id=683772 I'm going to attach 3 files lsofstart.out, lsotmid.out, and lsoflate.out. They
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 15:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 13:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Bill Burke (patriot1burke)
Date: 2003-01-10 17:30
Message:
Logged In: YES
user_id=176497
This is simulated XA dude.You can use ANY jdbc driver. The
XADataSourceLoader wraps a plain old JDBC driver and
simulates an XA resource.
AGAIN. YOU MUST USE XADataSourceLoader if you want
transaction support with your Entity Beans Just use it. IT
WILL WORK!
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 17:28
Message:
Logged In: YES
user_id=51762
In my case "Use XA" isn't viable. From Sybase, buying XA
capability means paying many, many dollars.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 17:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 17:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 18:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 17:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 17:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 13:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:28
Message:
Logged In: YES
user_id=51762
In my case "Use XA" isn't viable. From Sybase, buying XA
capability means paying many, many dollars.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 15:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-664547 ] JDBC pooling completely broken
Bugs item #664547, was opened at 2003-01-08 10:51
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
Category: JBossServer
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Kyle VanderBeek (kylev)
Assigned to: Nobody/Anonymous (nobody)
Summary: JDBC pooling completely broken
Initial Comment:
Crate a simple JDBC data source in jboss.jcml (we're
currently on 2.4.8):
com.sybase.jdbc2.jdbc.SybDriver,com.mysql.jdbc.Driver
CartDS
jdbc:mysql://db2.server.dom/cart?autoReconnect=true
user
pass
16
This pool is completely un-usable and will be quickly
exhausted with any simple code:
for (int i = 0; i < someNum; i++) {
Connection con = ds.getConnection();
con.close();
}
If you turn on tracing for "org.jboss.pool", you'll see
that the end of ObjectPool.releaseObject() is *never*
reached.
--
>Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 15:46
Message:
Logged In: YES
user_id=51762
I'm trying to use the XA method, but now I get a ton of these:
[15:41:13,994,XAConnectionFactory] XAConnectionImpl:
org.jboss.pool.jdbc.xa.wrapper.XAConnectionImpl@c0f2e5 has
no current tx!
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-10 14:30
Message:
Logged In: YES
user_id=176497
This is simulated XA dude.You can use ANY jdbc driver. The
XADataSourceLoader wraps a plain old JDBC driver and
simulates an XA resource.
AGAIN. YOU MUST USE XADataSourceLoader if you want
transaction support with your Entity Beans Just use it. IT
WILL WORK!
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:28
Message:
Logged In: YES
user_id=51762
In my case "Use XA" isn't viable. From Sybase, buying XA
capability means paying many, many dollars.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Submit the simplest testcase possible that demonstrates the
problem
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-10 14:23
Message:
Logged In: YES
user_id=51762
Test suite:
http://www.kylev.com/tmp/screwpool.zip
--
Comment By: Bill Burke (patriot1burke)
Date: 2003-01-08 15:14
Message:
Logged In: YES
user_id=176497
Use XADataSourceLoader. Its being used in many many
production sites around the world. In fact, if you want
transactions with your ejbs, you can't use a plain JDBC loader.
Don't count on this getting fixed anytime soon. 2.4.x series
development is basically retired except for paying support
customers.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
(Forgot to actually attach patch)
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 14:38
Message:
Logged In: YES
user_id=51762
Proposed patch (by my co-worker Blaise).
This alone is almost worth rolling a new release (IMHO). An
EJB server that can't reliably use a DataSource isn't worth
much.
--
Comment By: Kyle VanderBeek (kylev)
Date: 2003-01-08 10:59
Message:
Logged In: YES
user_id=51762
A quick glance by my co-worker found that the calls in
ObjectPool.releaseObject() may be the problem:
factory.returnObject(object);//do this first
pooled = factory.translateObject(object);
Looking at the JDBCConnectionFactory, pooled will ALWAYS be
null after these calls, because
JDBCConnectionFactory.returnObject() calls
ConnectionInPool.reset() which sets the underlying
connection to null.
Something here is incorrect, though I'm not sure yet what
the expected semmantics are.
------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=664547&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663934 ] IllegalStateException in AbstractInstanceCache
Bugs item #663934, was opened at 2003-01-07 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663934&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Nobody/Anonymous (nobody) Summary: IllegalStateException in AbstractInstanceCache Initial Comment: When I run ECperf with a txrate of 20 on Jboss 3.0.RC2, the following exception pops up every once in a while: 18:55:19,504 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: INSERTING AN ALREADY EXISTING BEAN, ID = 1041562119833 at org.jboss.ejb.plugins.AbstractInstanceCache.insert(AbstractInstanceCache.java:222) at org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager.createSession(StatefulSessionFilePersistenceManager.java:199) at org.jboss.ejb.StatefulSessionContainer.createHome(StatefulSessionContainer.java:441) at sun.reflect.GeneratedMethodAccessor208.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invokeHome(StatefulSessionContainer.java:763) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:105) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invokeHome(StatefulSessionInstanceInterceptor.java:128) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:62) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:129) at org.jboss.ejb.StatefulSessionContainer.invokeHome(StatefulSessionContainer.java:368) at org.jboss.ejb.Container.invoke(Container.java:730) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:554) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663934&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 11:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665183 ] 3.2RC1 w/Tomcat 4.1.18 startup error
Bugs item #665183, was opened at 2003-01-09 10:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665183&group_id=22866
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Cleveland (groovesoftware)
Assigned to: Nobody/Anonymous (nobody)
Summary: 3.2RC1 w/Tomcat 4.1.18 startup error
Initial Comment:
I have a fresh checkout of 3.2 code from CVS built with
integrated Tomcat 4.1.18, running on Solaris with Java
1.3.1. I get the following error attempting to startup
the default configuration.
2003-01-09 17:43:56,076 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner
] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedUR
L@9a82f7b8{
url=file:/home/mcleveland/work/agent/jboss-install/jboss-3.2.0RC1_to
mcat-4.1.18/server/default/deploy/tomcat41-service.xml,
deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in
init of file:/home/mcleve
land/work/agent/jboss-install/jboss-3.2.0RC1_tomcat-4.1.18/server/default/deploy
/tomcat41-service.xml; - nested throwable:
(org.jboss.deployment.DeploymentExcep
tion: - nested throwable: (java.lang.NullPointerException))
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:712)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404)
at
org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:545)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:195)
at
org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:268)
at
org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1
97)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:957)
at $Proxy0.start(Unknown Source)
at
org.jboss.system.ServiceController.start(ServiceController.java:388)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy5.start(Unknown Source)
at
org.jboss.deployment.SARDeployer.start(SARDeployer.java:299)
at
org.jboss.deployment.MainDeployer.start(MainDeployer.java:824)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:636)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:584)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy6.deploy(Unknown Source)
at
org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:325)
at
org.jboss.system.server.ServerImpl.start(ServerImpl.java:232)
at org.jboss.Main.boot(Main.java:155)
at org.jboss.Main$1.run(Main.java:393)
at java.lang.Thread.run(Thread.java:479)
+ nested throwable:
org.jboss.deployment.DeploymentException: - nested
throwable: (java.lang.NullPoi
nterException)
at
org.jboss.deployment.SARDeployer.init(SARDeployer.java:156)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:688)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:624)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:600)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea
nDispatcher.java:284)
at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549)
at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
at $Proxy7.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:404
[JBoss-dev] [ jboss-Bugs-665394 ] MDB pool size is not bounded -- Is the max size being read?
Bugs item #665394, was opened at 2003-01-09 15:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665394&group_id=22866 Category: JBossMQ Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Elias Ross (genman) Assigned to: Nobody/Anonymous (nobody) Summary: MDB pool size is not bounded -- Is the max size being read? Initial Comment: I don't really want to create 100 MDB for my application, so I changed the standardjboss.xml configuration (like I did in 3.2): --- standardjboss.xml Fri Dec 20 18:47:58 2002 +++ /home/eross/src/javapackages/jboss/server/default/conf/standardjboss.xml Thu Jan 9 14:22:38 2003 @@ -774,7 +774,7 @@ org.jboss.tm.TxManager -100 + 5 This doesn't seem to work and I end up with hundreds of threads (and eventually run out of sockets...) Actually setting this number to -1 or something else doesn't create any error... I end up with this in the logs: 2003-01-09 22:32:54,997 ERROR [JMSContainerInvoker] Exception in JMSCI message listener javax.ejb.TransactionRolledbackLocalException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused); CausedByException is: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:100) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.MessageDrivenContainer.invoke(MessageDrivenContainer.java:311) at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:697) at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:985) at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:241) at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:601) at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:415) at org.jboss.mq.SpySession.run(SpySession.java:293) at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655) at java.lang.Thread.run(Thread.java:536) javax.ejb.EJBException: null; CausedByException is: Cannot authenticate user; - nested throwable: (java.net.ConnectException: Connection refused) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665394&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666150 ] Cannot use discover for a HA-JNDI for another partition
Bugs item #666150, was opened at 2003-01-11 11:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666150&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Cannot use discover for a HA-JNDI for another partition Initial Comment: If a JBoss service wants to lookup another service that is reference in the HA-JNDI service running in another HA-Partition, automatic discovery cannot be used and the only way to lookup this service is by using an explicit PROVIDER_URL string. Currently, when PROVIDER_URL is not specified, the NamingContext will try to use the local server if available or do a discoverServer otherwise, independently of any JNP_PARTITION_NAME parameter that could have been specified in the naming properties. The source complain can be found here (as well as a start of resolution): http://www.jboss.org/modules.php? op=modload&name=phpBB_14&file=index&action=viewt opic&topic=26920&1 Work in progress. The fixed solution will most probably keep a table of (partition name => locally available HA- JNDI service) so that if the HA-JNDI service also runs locally, no network broadcast is necessary. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666150&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666154 ] HA-Home not refreshed in JNDI
Bugs item #666154, was opened at 2003-01-11 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666154&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: HA-Home not refreshed in JNDI Initial Comment: When a clustered container starts, it creates its home proxy and binds it in JNDI. In the clustered case, this proxy contains: - the list of currently available target containers - the version id used to keep track of the evolution of the cluster topology. The hypothesis that was made at first when coding that, is that the JNDI server do *not* marshall the home proxy that is bound in JNDI so that when the list of target containers is updated, the proxy always contain the last available information (the proxy as a reference to the list). Nevertheless, it appears that the JNDI service *do* serialized content at binding time. Consequently, the target list available in the proxy is the one that was available at container start time. Consequently, when getting the home for the first time, the list may not be up-to-date anymore. This has two important consequences: 1) homes that are used only once may always make invocations against the same set of nodes 2) (more important) when the list of target contains a proxy to a *dead* node, when the clustered proxy is unserialized by RMI, the RMI subsystem attempts to contact that node (!!). If the instance is simply dead, that's ok because it will quickly receive an answer from the target OS (port not open), but if the *host* is not reachable (not only the service), then the socket will have to wait on TCP timeout which may be quite long!!! Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666154&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666157 ] Version ID not updated in clustered proxy
Bugs item #666157, was opened at 2003-01-11 11:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666157&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Version ID not updated in clustered proxy Initial Comment: Proxies generated by EJB container never have their version id refreshed. Consequently, even if the target list received by a remote client is up-to-date, the version id is not and at the next call (i.e. for every first invocation), the (same) list of targets will be downloaded from the server (which use some bandwith, serialization, etc). Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666157&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663859 ] Deadlock in shutdown hooks when interrupting startup
Bugs item #663859, was opened at 2003-01-07 09:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663859&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Marquard (lurp) >Assigned to: Scott M Stark (starksm) Summary: Deadlock in shutdown hooks when interrupting startup Initial Comment: Steps to reproduce: While JBoss is starting up (i.e., deploying services, ejbs, etc.), hit Ctrl+C to halt the VM. About two thirds of the time a deadlock will happen in the shutdown hooks. JBoss version: 3.0.5rc1 JDK version: 1.4.1_01 OS: Windows XP The thread dump of the deadlock is attached. -- >Comment By: Scott M Stark (starksm) Date: 2003-01-11 03:13 Message: Logged In: YES user_id=175228 This has been fixed for 3.0.5. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663859&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-665067 ] Managed Connection equals Null! Problems in JBOSS 3.0.3
Bugs item #665067, was opened at 2003-01-09 15:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665067&group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Michael Ukpong (michaelukpong) >Assigned to: David Jencks (d_jencks) Summary: Managed Connection equals Null! Problems in JBOSS 3.0.3 Initial Comment: The .remove() method of some Entity beans I wrote and deployed in JBoss 3.0.0 is now throwing a "Managed Connection = null" exception in Jboss 3.0.3. I earlier noticed that these entities gave a "you are not getting the semantics you expect" warning (both in Jboss 3.0.0 and 3.0.3) but I ignored this warning in Jboss 3.0.0. Could this be the cause of the exception now thrown in Jboss 3.0.3? The funny thing is that if you keep looping on the remove (), where the number of iterations is the record length of the underlying table + 1, it eventually works! So its like the managed connection is restored after a certain number of failed attempts. What could this mean? Note that this remove() method is NOT called directly from a servlet, but through a stateless session bean. -- >Comment By: David Jencks (d_jencks) Date: 2003-01-11 13:41 Message: Logged In: YES user_id=60525 Please try 3.0.5 and see if the problem is already fixed. How about some details or a test case? BMP or CMP? If BMP, are you holding the connection between method invocations or getting it each time you need it? Have you defined .equals in your entity? Have you marked the datasource as an unsharable resource? Thanks david jencks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=665067&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666150 ] Cannot use discover for a HA-JNDI for another partition
Bugs item #666150, was opened at 2003-01-11 11:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666150&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Cannot use discover for a HA-JNDI for another partition Initial Comment: If a JBoss service wants to lookup another service that is reference in the HA-JNDI service running in another HA-Partition, automatic discovery cannot be used and the only way to lookup this service is by using an explicit PROVIDER_URL string. Currently, when PROVIDER_URL is not specified, the NamingContext will try to use the local server if available or do a discoverServer otherwise, independently of any JNP_PARTITION_NAME parameter that could have been specified in the naming properties. The source complain can be found here (as well as a start of resolution): http://www.jboss.org/modules.php? op=modload&name=phpBB_14&file=index&action=viewt opic&topic=26920&1 Work in progress. The fixed solution will most probably keep a table of (partition name => locally available HA- JNDI service) so that if the HA-JNDI service also runs locally, no network broadcast is necessary. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666150&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666157 ] Version ID not updated in clustered proxy
Bugs item #666157, was opened at 2003-01-11 11:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666157&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: Version ID not updated in clustered proxy Initial Comment: Proxies generated by EJB container never have their version id refreshed. Consequently, even if the target list received by a remote client is up-to-date, the version id is not and at the next call (i.e. for every first invocation), the (same) list of targets will be downloaded from the server (which use some bandwith, serialization, etc). Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666157&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666154 ] HA-Home not refreshed in JNDI
Bugs item #666154, was opened at 2003-01-11 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666154&group_id=22866 Category: Clustering Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sacha Labourey (slaboure) Assigned to: Sacha Labourey (slaboure) Summary: HA-Home not refreshed in JNDI Initial Comment: When a clustered container starts, it creates its home proxy and binds it in JNDI. In the clustered case, this proxy contains: - the list of currently available target containers - the version id used to keep track of the evolution of the cluster topology. The hypothesis that was made at first when coding that, is that the JNDI server do *not* marshall the home proxy that is bound in JNDI so that when the list of target containers is updated, the proxy always contain the last available information (the proxy as a reference to the list). Nevertheless, it appears that the JNDI service *do* serialized content at binding time. Consequently, the target list available in the proxy is the one that was available at container start time. Consequently, when getting the home for the first time, the list may not be up-to-date anymore. This has two important consequences: 1) homes that are used only once may always make invocations against the same set of nodes 2) (more important) when the list of target contains a proxy to a *dead* node, when the clustered proxy is unserialized by RMI, the RMI subsystem attempts to contact that node (!!). If the instance is simply dead, that's ok because it will quickly receive an answer from the target OS (port not open), but if the *host* is not reachable (not only the service), then the socket will have to wait on TCP timeout which may be quite long!!! Work in progress. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666154&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-666392 ] XML fixes
Patches item #666392, was opened at 2003-01-12 00:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=666392&group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Ville Skyttä (scop) Assigned to: Nobody/Anonymous (nobody) Summary: XML fixes Initial Comment: Here's a patch containing multiple XML validity fixes for files in JBoss 3.0, basically just moving around things. The patch is against CVS Branch_3_0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=666392&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-663114 ] MarshallException when accessing remote bean
Bugs item #663114, was opened at 2003-01-06 05:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=663114&group_id=22866 >Category: JBossTX Group: v3.0 Rabbit Hole Status: Open >Resolution: Postponed Priority: 5 Submitted By: Maxim (kimerinn) Assigned to: Nobody/Anonymous (nobody) Summary: MarshallException when accessing remote bean Initial Comment: Hi! Scenario: 1) I have two session beans A and B, each of them have remote interfaces. A obtains home & remote interface of bean B and invokes method B.hello(). 2) When both beans are locating on the same machine, all works Ok. 3) When bean A is hosting on one computer and bean B on second, bean A obtains home interface of bean B and obtain exception when creating remote interface of bean B. 4) When the bean B is accesed fom another computer through application client, all works Ok. Here is full stack trace: = 13:16:12,169 ERROR [STDERR] java.rmi.MarshalException: error marshalling arguments; nested exception is: java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] java.io.NotSerializableException: org.jboss.tm.TransactionImpl 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1148) 13:16:12,169 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:377) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1172) 13:16:12,179 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:366) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:268) 13:16:12,179 ERROR [STDERR] at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:106) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:138) 13:16:12,179 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:108) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:77) 13:16:12,179 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:198) 13:16:12,220 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) 13:16:12,220 ERROR [STDERR] at $Proxy25.create(Unknown Source) 13:16:12,220 ERROR [STDERR] at aside.ABean.testB(ABean.java:46) 13:16:12,220 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,220 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:660) 13:16:12,220 ERROR [STDERR] at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:107) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:178) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:60) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) 13:16:12,230 ERROR [STDERR] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) 13:16:12,240 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:712) 13:16:12,240 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) 13:16:12,240 ERROR [STDERR] at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:382) 13:16:12,240 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport$1.run(Transport.java:152) 13:16:12,240 ERROR [STDERR] at java.security.AccessController.doPrivileged(Native Method) 13:16:12,240 ERROR [STDERR] at sun.rmi.transport.Transport.serviceCall(Transport.java:148) 13:16:12,240
[JBoss-dev] [ jboss-Bugs-666662 ] Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Bugs item #62, was opened at 2003-01-12 15:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Initial Comment:
I know this has been reported before, but the blurb for
3.0.5 was interested in checking whether these types of
errors had been fixed.
First time round everything works fine. On a redeploy I
get a class cast exception, during a narrow call:
14:38:25,625 ERROR [system] [Exception passed to
ExceptionHelper]
14:38:25,639 ERROR [system] Stack trace...
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeImpl.(GUIFacadeImpl.java:52)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeFactory.getInstance(GUIFacadeFactory.java:30)
The Java leading up to this is a standard JNDI lookup
sequence:
public GUIFacadeImpl(Hashtable env) throws
FacadeException {
if (_ejbHome == null) {
try {
InitialContext context = (env == null) ? new
InitialContext() : new InitialContext(env);
Object obj = context.lookup(DEFAULT_JNDI_NAME);
this._ejbHome = (GUIServiceHome)
PortableRemoteObject.narrow(obj, GUIServiceHome.class);
} catch (Exception e) {
ExceptionHelper.logException(e);
throw new FacadeException(e);
}
}
}
Start of server.log
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss
JAVA: /usr/java/bin/java
JAVA_OPTS:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Dprogram.name=run.sh
CLASSPATH:
/usr/local/jboss/bin/run.jar:/usr/java/lib/tools.jar
15:00:14,001 INFO [Server] JBoss Release:
JBoss-3.0.5RC1 CVSTag=JBoss_3_0_5_RC1
15:00:14,035 INFO [Server] Home Dir:
/usr/local/jboss-3.0.5RC1
15:00:14,048 INFO [Server] Home URL:
file:/usr/local/jboss-3.0.5RC1/
15:00:14,061 INFO [Server] Library URL:
file:/usr/local/jboss-3.0.5RC1/lib/
15:00:14,075 INFO [Server] Patch URL: null
15:00:14,087 INFO [Server] Server Name: default
15:00:14,100 INFO [Server] Server Home Dir:
/usr/local/jboss-3.0.5RC1/server/default
15:00:14,112 INFO [Server] Server Home URL:
file:/usr/local/jboss-3.0.5RC1/server/default/
15:00:14,125 INFO [Server] Server Data Dir:
/usr/local/jboss-3.0.5RC1/server/default/db
15:00:14,138 INFO [Server] Server Temp Dir:
/usr/local/jboss-3.0.5RC1/server/default/tmp
15:00:14,150 INFO [Server] Server Config URL:
file:/usr/local/jboss-3.0.5RC1/server/default/conf/
15:00:14,163 INFO [Server] Server Library URL:
file:/usr/local/jboss-3.0.5RC1/server/default/lib/
15:00:14,176 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
15:00:14,192 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:00:14,575 INFO [ServerInfo] Java version:
1.4.1_01,Sun Microsystems Inc.
15:00:14,590 INFO [ServerInfo] Java VM: Java
HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.
15:00:14,603 INFO [ServerInfo] OS-System: Linux
2.4.20,i386
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666701 ] Incompatibility in run.sh (: not found)
Bugs item #666701, was opened at 2003-01-12 17:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666701&group_id=22866 Category: None Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Incompatibility in run.sh (: not found) Initial Comment: When starting Jboss on: FreeBSD 4.6-STABLE Sun JDK 1.3.1 It starts with: : not found : not found : not found : not found : not found : not found : not found = === JBoss Bootstrap Environment JBOSS_HOME: /soze/home/stefan/Java/jboss-3.2.0B3 JAVA: /usr/local/jdk1.3.1/bin/java JAVA_OPTS: -Dprogram.name=run.sh CLASSPATH: /soze/home/stefan/Java/jboss- 3.2.0B3/bin/run.jar:/usr/local/jdk1.3.1/lib/tools.jar = === Other than that the server boots fine. Stefan Arentz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666701&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666702 ] Debug messages in INFO priority
Bugs item #666702, was opened at 2003-01-12 17:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666702&group_id=22866 Category: JBossCMP Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Debug messages in INFO priority Initial Comment: 2003-01-12 17:48:04,259 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCRemoveEntityCom mand.User] Checking if already deleted: 35400 2003-01-12 17:48:04,259 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCRemoveEntityCom mand.User] Deleteing: 35400 These should not show up under INFO, the log quickly fills with thousands of these when deleting many objects. Stefan Arentz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666702&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666704 ] Deploying SARs via application.xml barfs
Bugs item #666704, was opened at 2003-01-12 18:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Arentz (sateh) Assigned to: Nobody/Anonymous (nobody) Summary: Deploying SARs via application.xml barfs Initial Comment: In a recent message on the mailinglist I found that you have to add a .sar to your application.xml like this: mccp.sar However, this throws an exception while deploying: org.jboss.deployment.DeploymentException: exception in init of file:/soze/home/stefan/Java/jboss- 3.2.0B3/server/default/deploy/mccp.ear; - nested throwable: (org.jboss.deployment.DeploymentException: Service archives must be in jboss-app.xml) It refers to jboss-app.xml, which does not exist in JBoss 3.2. Stefan Arentz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=666704&group_id=22866 --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-666662 ] Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Bugs item #62, was opened at 2003-01-12 15:08
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Loz (lozzer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Still problems redeploying with JDK 1.4 and jboss-3.0.5RC1
Initial Comment:
I know this has been reported before, but the blurb for
3.0.5 was interested in checking whether these types of
errors had been fixed.
First time round everything works fine. On a redeploy I
get a class cast exception, during a narrow call:
14:38:25,625 ERROR [system] [Exception passed to
ExceptionHelper]
14:38:25,639 ERROR [system] Stack trace...
java.lang.ClassCastException
at
com.sun.corba.se.internal.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:293)
at
javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:134)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeImpl.(GUIFacadeImpl.java:52)
at
uk.co.ecsoft.justine.component.gui.service.GUIFacadeFactory.getInstance(GUIFacadeFactory.java:30)
The Java leading up to this is a standard JNDI lookup
sequence:
public GUIFacadeImpl(Hashtable env) throws
FacadeException {
if (_ejbHome == null) {
try {
InitialContext context = (env == null) ? new
InitialContext() : new InitialContext(env);
Object obj = context.lookup(DEFAULT_JNDI_NAME);
this._ejbHome = (GUIServiceHome)
PortableRemoteObject.narrow(obj, GUIServiceHome.class);
} catch (Exception e) {
ExceptionHelper.logException(e);
throw new FacadeException(e);
}
}
}
Start of server.log
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss
JAVA: /usr/java/bin/java
JAVA_OPTS:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
-Dprogram.name=run.sh
CLASSPATH:
/usr/local/jboss/bin/run.jar:/usr/java/lib/tools.jar
15:00:14,001 INFO [Server] JBoss Release:
JBoss-3.0.5RC1 CVSTag=JBoss_3_0_5_RC1
15:00:14,035 INFO [Server] Home Dir:
/usr/local/jboss-3.0.5RC1
15:00:14,048 INFO [Server] Home URL:
file:/usr/local/jboss-3.0.5RC1/
15:00:14,061 INFO [Server] Library URL:
file:/usr/local/jboss-3.0.5RC1/lib/
15:00:14,075 INFO [Server] Patch URL: null
15:00:14,087 INFO [Server] Server Name: default
15:00:14,100 INFO [Server] Server Home Dir:
/usr/local/jboss-3.0.5RC1/server/default
15:00:14,112 INFO [Server] Server Home URL:
file:/usr/local/jboss-3.0.5RC1/server/default/
15:00:14,125 INFO [Server] Server Data Dir:
/usr/local/jboss-3.0.5RC1/server/default/db
15:00:14,138 INFO [Server] Server Temp Dir:
/usr/local/jboss-3.0.5RC1/server/default/tmp
15:00:14,150 INFO [Server] Server Config URL:
file:/usr/local/jboss-3.0.5RC1/server/default/conf/
15:00:14,163 INFO [Server] Server Library URL:
file:/usr/local/jboss-3.0.5RC1/server/default/lib/
15:00:14,176 INFO [Server] Root Deployemnt Filename:
jboss-service.xml
15:00:14,192 INFO [Server] Starting General Purpose
Architecture (GPA)...
15:00:14,575 INFO [ServerInfo] Java version:
1.4.1_01,Sun Microsystems Inc.
15:00:14,590 INFO [ServerInfo] Java VM: Java
HotSpot(TM) Client VM 1.4.1_01-b01,Sun Microsystems Inc.
15:00:14,603 INFO [ServerInfo] OS-System: Linux
2.4.20,i386
--
>Comment By: Adrian Brock (ejort)
Date: 2003-01-12 17:36
Message:
Logged In: YES
user_id=9459
The 3.0.5RC1 binary release was built with 1.3 so
it does not include the 1.4 RMIClassLoader workaround.
It won't compile on 1.3 :-(
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jboss/jboss-
system/src/main/org/jboss/system/JBossRMIClassLoader.jav
a?annotate=1.1.2.1
If you build the source release on 1.4 it will be included
in run.jar
Alternatively, download the above class, compile it
and add it to the classpath.
Ideally, you should not be using the RMI layer
when you are in the same VM.
Regards,
Adrian
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=62&group_id=22866
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
