AW: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Strike!
CGJ
-Ursprüngliche Nachricht-
Von: Alarik Myrin [mailto:[EMAIL PROTECTED]]
Gesendet: Donnerstag, 25. April 2002 06:24
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
WAIT! EVERYTHING WORKS FINE!
Don't i feel like a dumb ass. Although I got the new code and built it,
when I went to copy the jars to the directory that I usually run out of
(don't ask...bad habits are hard to break), somehow the jboss-jmx-core.jar
and jboss-jmx-services.jar were still in the directory from when i built the
3.0.0RC1 release (they don't seem to get built with the MAIN branch of the
code). So the wrong version of the classes were being loaded in (ironic,
don't you think?) The line numbers in the stack traces should have given it
away hours ago. well, at least it's given me a chance to review the fix,
and i have to say: very nice. if i had to spend all night chasing down a
bug that wasn't there, at least i learned something.
Sorry if I scared anybody, or wasted anybody's time...
alarik
-Original Message-
From: Alarik Myrin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 24, 2002 8:22 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Workaround for JUNG's RFE and load deadlock
Alas, I am getting a little further, but still getting a deadlock.
Below please find the relavent stack traces. Here is my take on what
they might mean, in case it is interesting to you:
There are two relavent threads. One (the first stack trace) is trying
to load a class needed by a stateless session bean in an effor to
deploy the bean. The class does not exist in the bean's jar file,
instead it exists in a another archive called picasso.zip. The other
(the second stack trace), was spawned by a class found in picasso.zip.
It is trying to load a class from (I suspect) a third party jar file
called osji.jar. Because there is a seperate class loader for each
archive, the deadlock becomes possible. Does this sound right? (I am
not really an expert at class loading, but learning as I go :).
What makes this problem quite tricky (it seems to me) is that in both
threads the UnifiedClassLoader instance is _already locked_ by the
time _any_ of its methods are even executed.
What about this: instead of
/**
* We intercept the load class to know exactly the dependencies
* of the underlying jar.
*
* pForwards request to {@link UnifiedLoaderRepository}.
*/
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized(this)
{
return repository.loadClass(name, resolve, this);
}
}
What if we did this:
/**
* We intercept the load class to know exactly the dependencies
* of the underlying jar.
*
* pForwards request to {@link UnifiedLoaderRepository}.
*/
public Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized(this.getClass())
{
return repository.loadClass(name, resolve, this);
}
}
Another observation: startup appears to be taking noticably longer
than it did with JBoss 2.4.x, even in parts of the startup process
where I suspect it is mostly just executing my code. The CPU just
spikes like crazy. Whenever I do a thread dump to check what it is up
to, it always appears to be trying to load a class. Startup time
isn't the most important thing in the world, but it does impact the
speed of development (although I suspect that if I really understood
the power of the deploy/undeploy functionality of JBoss 3, I wouldn't
need to restart the server nearly so often...).
Anyway, I hope all of this helps. I'll be available all week to run
any tests you'd like, but then I start traveling for almost a month...
Alarik
main prio=5 tid=0xc7d640 nid=0x157 waiting for monitor entry
[0x93fd000..0x93ffdc0]
at java.lang.ClassLoader.loadClass(ClassLoader.java:286)
- waiting to lock 3329c48 (a
org.jboss.mx.loading.UnifiedClassLoader)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedCl
assLoader.java:180)
at
org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoad
erRepository.java:178)
at
org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoad
er.java:217)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313)
- locked 330edc0 (a org.jboss.mx.loading.UnifiedClassLoader)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:195)
at com.odi.ClassInfo.lookupClassInfoByName(ClassInfo.java:608)
at com.odi.ClassInfo.lookupClassInfoByName(ClassInfo.java:589)
at com.odi.ClassInfo.findAndRegister(ClassInfo.java:502)
at com.odi.ClassInfo.get(ClassInfo.java:483)
[JBoss-dev] Automated JBoss Testsuite Results: 25-April-2002
Number of tests run: 578 Successful tests: 562 Errors:11 Failures: 5 [time of test: 25 April 2002 7:49 GMT] [java.version: 1.4.0] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.0-b92] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_j2sdk140 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-548459 ] MBean version management
Patches item #548459, was opened at 2002-04-25 16:08 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=548459group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Fusayuki Minamoto (minamoto) Assigned to: Nobody/Anonymous (nobody) Summary: MBean version management Initial Comment: This patch changes MLet#getMBeansFromURL() and allows MLet to handle the VERSION attribute in the MLet conf files. JMX spec p.129 states that this version number can be used to specify whether or not the JAR files need to be loaded from the server to update those already loaded by the m-let service. The pached MLet checks the version and install or upgrade depend on the verson value. If it found the registered mbean, it unregisters it first and then registers the new mbean. This change is still experimental because JMX spec doesn't fully specify the version handling for mbeans. In this change, the version base upgrade only happens when previous version and new version are specified. Otherwise MLet forces to install the mbeans. Attached zip file includes the patch and the unit test. This is already passed by test-compliance and test- implementation target of JMX build.xml about MLet tests. Regards, Miki -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=548459group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Jasper JspWriterImpl.initOut bug
Ok... I think I could be loosing my mind. All uf a sudden this works now, with out this hack. But now I get exceptions like this when using error pages: 01:12:58,093 WARN [Jetty] WARNING: GET /default.jsp HTTP/1.1 java.lang.NullPointerException at org.mortbay.http.ChunkableOutputStream.write(ChunkableOutputStream.java:381) at org.mortbay.jetty.servlet.ServletOut.write(ServletOut.java:42) at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:230) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:244) at java.io.BufferedWriter.flush(BufferedWriter.java:233) at java.io.PrintWriter.flush(PrintWriter.java:120) at org.mortbay.jetty.servlet.Dispatcher$DispatcherResponse.flushBuffer(Dispatcher.java:570) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:327) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:171) at com.opensymphony.module.sitemesh.filter.PageFilter.applyDecorator(PageFilter.java) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java) at org.mortbay.jetty.servlet.FilterHandler$Chain.doFilter(FilterHandler.java:297) at org.mortbay.jetty.servlet.FilterHandler.handle(FilterHandler.java:228) at org.mortbay.http.HttpContext.handle(HttpContext.java:1357) at org.mortbay.http.HttpContext.handle(HttpContext.java:1309) at org.mortbay.http.HttpServer.service(HttpServer.java:744) at org.jboss.jetty.Jetty.service(Jetty.java:527) at org.mortbay.http.HttpConnection.service(HttpConnection.java:743) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287) at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715) at java.lang.Thread.run(Thread.java:484) But perhaps this will go away too? I don't think so... I think I am stuck with one or the other. This one only seems to pop up when using error pages, so perhaps that isn't soo bad... still shouldn't happen. =( --jason * * * View thread online: http://jboss.org/forums/thread.jsp?forum=66thread=13529 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [JBoss-dev] Jetty, Servlet Filters url-pattern=/*(fwd)
Jason, I just did a quick test on raw jetty, and a filter at /* certainly is getting applied to a webapp that is registered at / If I register the webapp at /blah then the filter also gets called for http://localhost:8080/blah requests. Can you use the JMX interface to turn on Jetty debugging and see what is happening within the filter handler (Jules/Jan the debug MBean is work now right) cheers -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [JBoss-dev] Jetty, Servlet Filters url-pattern=/* (fwd)
Really... that is odd. Are you testing on your latest CVS? I have been using the version in JBoss CVS HEAD using the SiteMesh filter (http://www.opensymphony.com/sitemesh/) and I could only get it to apply the decorator to http://localhost:8080/index.jsp it would show the raw content page for http://localhost:8080 I tested this over and over... though it is possible that I am insane after all this mudling... but another user on jboss dev confirmed the odd behavior. I am moving forward with my work on the site, using index.jsp to send a redirect to default.jsp which seems to work. If you still can not reproduce, perhaps it is fixed in the latest... otherwise once the new site is setup using these filters you can use that to test (copying default.jsp to index.jsp). Or I could mail you a test war... yes perhaps that is best. I tried enabling debug with the jboss.web:Jetty=Debug MBean but it did not produce any useful output: [SocketListener-4/0]javax.servlet.GenericServlet.init(GenericServlet.java:257) Perhaps it still does not work? I don't know. --jason Quoting Greg Wilkins [EMAIL PROTECTED]: Jason, I just did a quick test on raw jetty, and a filter at /* certainly is getting applied to a webapp that is registered at / If I register the webapp at /blah then the filter also gets called for http://localhost:8080/blah requests. Can you use the JMX interface to turn on Jetty debugging and see what is happening within the filter handler (Jules/Jan the debug MBean is work now right) cheers -- Greg Wilkins[EMAIL PROTECTED] GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Where can I find info about build of dedicated axis engine for Macromedia Flash?
Hi, I saw JBoss task on SourceForge at url: http://sourceforge.net/pm/task.php?func=detailtaskproject_task_id=52768gro up_id=22866group_project_id=13975 which seems to me very exciting and interesting. Where could I find some info about this project? Regards, Radoslaw Sliwinski MAD Multimedia Art Design ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss-3.0.1alpha (25.04 cvs version) hangs on start up
I just have checked jboss-all from cvs, built with J2SDK1.4.0 under Win2K and got this exception on start up: 2002-04-25 12:01:03,790 INFO [org.jboss.resource.connectionmanager.XATxConnectionManager] Creating 2002-04-25 12:01:03,800 ERROR [org.jboss.management.j2ee.JCAConnectionFactory] Could not create JSR-77 JCAConnectionFactory: null RuntimeMBeanException: org.jboss.management.j2ee.JCAConnectionFactory constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerI mpl.java:828) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:790) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:212) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:253) at org.jboss.management.j2ee.JCAConnectionFactory.create(JCAConnectionFactory.j ava:193) at org.jboss.resource.connectionmanager.BaseConnectionManager2.createService(Ba seConnectionManager2.java:250) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy10.create(Unknown Source) at org.jboss.resource.RARDeployer.create(RARDeployer.java:181) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:649) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:524) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:488) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstract DeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) 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.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:341) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
Hi again, I dont know if I have al possible error conditions in my head, and my excperiences are based on the 2.4.3 code. Also remember that the current JMS RA does not have any support for reconnect or exception listener. What we basically want is failover, i.e the JMS provider in this case (or a db I guess in other cases) has gone down and come up again. 1. The case where the EIS is down when the client is doing a call should be transparent. The client gets an exception and the mc uses the listener to invalidate that mc in the pool. Things gets more complicated when the EIS has come back. One verry important restriction here is that the spec says that an instance of an mc must allways return the same XAResource! 2. The client gets an handle, probably from the pool. a) If the RA does not have an asynchronous exception mechanism (as JMS have), we are in big trubble. The server side JCA stuff will macth an existring mc, will atach a listener and get the XAResource, and if this is correctly done that XAResource will actually not be valid any more, something like this will be reported: [SMSTransport] XAException: tx=XidImpl [FormatId=257, GlobalId=linutv1//10, BranchQual=] errorCode=XAER_NOTA [SMSTransport] javax.transaction.xa.XAException Since we have, per spec to return the same XAResource for a mc we are not allowed to do magic here, i.e check if the resource has bee invalidated due to connection outake and make a new connection and return a new and valid XAResource. What could we do here: verry hard to say: In the API it says the getXAResource may throw a javax.resource.spi.ResourceAdapterInternalException to indicate that the mc is not valid any more. This could perhaps be used to invalidate the mc, and let the JCA stuff simple create a new one. b) If it has asynchronous support the listener API could be used to propagate the invalidation. I do not know if it is reallt spec compliant not to set the listener every time the mc is taken from the pool, but the way you have done it seems to do it easy to have asynchronous error reporting/invalidation. I guess it is also important for an XAResource that is invalid in the way described before is never enlisted in the tm. What I am trying to say is simply this: XA capable mc:s for wich the connection has gone down, but the EIS has come up agains, needs to invalidated in a transparent way for the client using it. //Peter On 24 Apr, David Jencks wrote: On 2002.04.24 15:48:16 -0400 [EMAIL PROTECTED] wrote: On 24 Apr, David Jencks wrote: So the problem you had was that ManagedConnection.getXAResource was called before ManagedConnection.addConnectionEventListener? It is always dangerous to claim things about code, but I am sure that ManagedConnection.addConnectionEventListener is always called before ManagedConnection.getXAResource in the new implementation. When connectionErrorOccurred is called, the ManagedConnection is destroyed and removed from the pool. IMO with a compliant adapter, this will result in all the connection handles associated with that ManagedConnection becoming unattached to any ManagedConnection. In the new implementation, if you cache connection handles accross method invocations, in the next invocation these handles will be associated with a presumably valid ManagedConnection obtained from the pool or newly created. Again IMO the adapter should throw enough of an exception to roll back the current tx if the physical connection dies. This sounds OK. If you try to get an mc, and these things happens (i.e whan you add the listener add will emediately be called at connectionErrorOccurred, what happends then, do you try to get a new mc from the pool (which probaly are dead all of them), or do you create a new mc. I haven't thought about these asynchronous possibilities before. The adapter is supposed to call the connectionErrorOccurred on the listeners and then through an exception to the client. Is there any way to do that, even when you know there is a client? I'd imagine that when there isn't, no problem. The basic problem here is that when using an ExceptionListener with JMS the connectio error can happen any time. If the mc is in use, it will be noticed and all is fine, but if the mc is in the pool, the only way it can raise the error is to wait for a listener to become added when it is above to be moved from the pool into an active state. Again, I haven't thought through this asynchronous case, but it might work fine as is. In the new system, a ManagedConnection gets one ConnectionEventListener throughout its entire lifespan, and keeps it while it is pooled. I haven't checked my destroy/kill logic, but it should be possible to deal with these events properly even when the managed connection is in the pool. Is there any chance you have tests for this behavior? Or any more bad cases to be aware of? This is getting interesting! Thanks
[JBoss-dev] [ jboss-Bugs-548051 ] Bug in StatefulSessionInstanceCache
Bugs item #548051, was opened at 2002-04-24 05:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548051group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 7 Submitted By: Christian Riege (lqd) Assigned to: Scott M Stark (starksm) Summary: Bug in StatefulSessionInstanceCache Initial Comment: There seems to be a rather serious bug regarding Stateful Session Beans. After having my server running for a time I got this exception: 13:47:39,083 ERROR [STDERR] java.lang.NullPointerException 13:47:39,083 ERROR [STDERR] at org.jboss.ejb.plugins.StatefulSessionInstanceCache.removePassivated(StatefulSessionInstanceCache.java:127) 13:47:39,083 ERROR [STDERR] at org.jboss.ejb.plugins.LRUStatefulContextCachePolicy$RemoverTask.run(LRUStatefulContextCachePolicy.java:138) 13:47:39,083 ERROR [STDERR] at java.util.TimerThread.mainLoop(Timer.java:430) 13:47:39,083 ERROR [STDERR] at java.util.TimerThread.run(Timer.java:380) the server continues to run but once a jar gets deployed/redeployed, the stacktraces just go on and on (just the first part of the trace, can post more if wanted): 14:19:06,259 ERROR [EntityContainer] Exception in service lifecyle operation: start java.lang.IllegalStateException: Timer already cancelled. at java.util.Timer.sched(Timer.java:310) at java.util.Timer.schedule(Timer.java:126) at org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy.start(LRUEnterpriseContextCachePolicy.java:129) at org.jboss.ejb.plugins.AbstractInstanceCache.start(AbstractInstanceCache.java:308) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:373) [...] this is against an 3.0.0RC1 build as of yesterday. BTW: The client accessing the StatefulSessionBean didn't call remove() on it so it had been idling in the container for a while ... sorry if this report is not clear enough but i don't have sufficient time to evaluate this further right now. -- Comment By: Scott M Stark (starksm) Date: 2002-04-25 02:31 Message: Logged In: YES user_id=175228 Try the Branch_3_0 fix and reopen with more information on the app if the exceptions still exist. -- Comment By: Scott M Stark (starksm) Date: 2002-04-24 11:16 Message: Logged In: YES user_id=175228 Its all part of the container memory leak cleanup showing that the passivation threads usage is not well designed with regard to container shutdowns. I'll look at fixing this. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548051group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss-3.0.1alpha (25.04 cvs version) hangs on start up
The exception should not be a problem, but hanging is. Your version info is a little inconsistent, but if it is 3.1 (HEAD) then I am not getting this hang on sun jdk 1.4 on linux 2.4.16. Try changing the name of the jmsra mbeansa to jboss.jca:service=XaTxCM,name=jmsra jboss.jca:service=XaTxDS,name=jmsra jboss.jca:service=XaTxPool,name=jmsra That should eliminate the exception, does it still hang? thanks david jencks On 2002.04.25 05:08:51 -0400 Alex Loubyansky wrote: I just have checked jboss-all from cvs, built with J2SDK1.4.0 under Win2K and got this exception on start up: 2002-04-25 12:01:03,790 INFO [org.jboss.resource.connectionmanager.XATxConnectionManager] Creating 2002-04-25 12:01:03,800 ERROR [org.jboss.management.j2ee.JCAConnectionFactory] Could not create JSR-77 JCAConnectionFactory: null RuntimeMBeanException: org.jboss.management.j2ee.JCAConnectionFactory constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerI mpl.java:828) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:790) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:212) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:253) at org.jboss.management.j2ee.JCAConnectionFactory.create(JCAConnectionFactory.j ava:193) at org.jboss.resource.connectionmanager.BaseConnectionManager2.createService(Ba seConnectionManager2.java:250) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy10.create(Unknown Source) at org.jboss.resource.RARDeployer.create(RARDeployer.java:181) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:649) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:524) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:488) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstract DeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) 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.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at
RE: [JBoss-dev] JBoss-3.0.1alpha (25.04 cvs version) hangs on start up
I got messed with JBoss versions I have... Sorry, today's version doesn't hang. Sorry, guys. But the exception really takes place. David, I could only find jboss.jca:service=XaTxCM,name=FirebirdDS in login-config.xml. After changing FirebirdDS to jmsra I got another exception: 2002-04-25 16:02:02,181 ERROR [org.jboss.management.j2ee.JCAConnectionFactory] Could not create JSR-77 JCAConnectionFactory: null RuntimeMBeanException: org.jboss.management.j2ee.JCAConnectionFactory constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerI mpl.java:828) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:790) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:212) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:253) at org.jboss.management.j2ee.JCAConnectionFactory.create(JCAConnectionFactory.j ava:193) at org.jboss.resource.connectionmanager.BaseConnectionManager2.createService(Ba seConnectionManager2.java:250) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy9.create(Unknown Source) at org.jboss.resource.RARDeployer.create(RARDeployer.java:181) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:649) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:524) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:488) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstract DeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) 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.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:341) at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source) at
Re: [JBoss-dev] JBoss-3.0.1alpha (25.04 cvs version) hangs on start up
Need more coffee before writing in the morning... I'll look at the exceptions from the jsr-77 stuff, but they should never obstruct your use of jboss, and it looks like they aren't now. The iiop stuff seems to be much improved recently, and hsqldb is just plain weird. The best way to avoid hanging on its shutdown is to use a different db entirely or pray;-) Actually I think it doesn't like being told to shut down if it is not entirely started -- this may have happened since startup didn't complete due to the iiop stuff. thanks david jencks On 2002.04.25 09:16:02 -0400 Alex Loubyansky wrote: I got messed with JBoss versions I have... Sorry, today's version doesn't hang. Sorry, guys. But the exception really takes place. David, I could only find jboss.jca:service=XaTxCM,name=FirebirdDS in login-config.xml. After changing FirebirdDS to jmsra I got another exception: 2002-04-25 16:02:02,181 ERROR [org.jboss.management.j2ee.JCAConnectionFactory] Could not create JSR-77 JCAConnectionFactory: null RuntimeMBeanException: org.jboss.management.j2ee.JCAConnectionFactory constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerI mpl.java:828) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:790) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:212) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:253) at org.jboss.management.j2ee.JCAConnectionFactory.create(JCAConnectionFactory.j ava:193) at org.jboss.resource.connectionmanager.BaseConnectionManager2.createService(Ba seConnectionManager2.java:250) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at org.jboss.system.ServiceController.create(ServiceController.java:283) at org.jboss.system.ServiceController.create(ServiceController.java:211) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy9.create(Unknown Source) at org.jboss.resource.RARDeployer.create(RARDeployer.java:181) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:649) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:524) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:488) at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(Abstract DeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
[JBoss-dev] [ jboss-Bugs-548586 ] CMP entity bean remove from JSP fails
Bugs item #548586, was opened at 2002-04-25 15:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548586group_id=22866 Category: CatalinaBundle Group: None Status: Open Resolution: None Priority: 5 Submitted By: Petr Hubený (psh) Assigned to: Scott M Stark (starksm) Summary: CMP entity bean remove from JSP fails Initial Comment: I've a CMP entity EJB with class PK. Using findByPrimaryKey() and remove() works fine from standalone client, however fails from JSP under 2.4.5RC2 with Tomcat/Catalina 4.0.3. It also works under 2.4.4 with Tomcat 3.2.3. The failure is accompanied with Failed to load/IllegalArgumentException screams, which appears strange, since the bean is already successfully loaded (the findByPrimaryKey() is OK, also getters on the bean work fine, just the remove() fails). Simple example of failure is attached, try the /Test/test.jsp to insert and (fail to) remove data (master and slave are integers, value is String). Oh, yeah, I tried the bundle JBoss-2.4.5_Tomcat-4.0.3.zip (it is RC1, I believe) on Linux with JDK 1.4.0-b92 and on Windows with JDK 1.4.0-b92 and JDK 1.3.1_01, fails everywhere. Then I tried JBoss-2.4.5RC2_Tomcat-4.0.3.zip on Linux (JDK 1.4.0), fails as well. Next I tried the old JBoss-2.4.4_Tomcat-3.2.3.zip on Linux (JDK 1.4.0) and it works. psh -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548586group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548625 ] Deploying MBEAN Message
Bugs item #548625, was opened at 2002-04-25 14:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548625group_id=22866 Category: JBossMX Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Theo Harper (btharper) Assigned to: Nobody/Anonymous (nobody) Summary: Deploying MBEAN Message Initial Comment: When trying to hot deploy an MBean into the latest JBOSS 3.1.0(alpha), and am getting the following warnings in the console: 15:22:38,769 WARN [MainDeployer] The manifest entry in file:/H:/EvoDev/Evolution/framework/services/deployment /build/lib/framework-deployment.sar references URL file:/H:/EvoDev/Evolution/framework/services/deployment /build/lib/library/log4j.jar which could not be opened, entry ignored. The manifest is correct, and the jar files are in the manifest. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548625group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548628 ] Error starting JBoss 3.1.0 (alpha)
Bugs item #548628, was opened at 2002-04-25 14:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548628group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Theo Harper (btharper) Assigned to: Nobody/Anonymous (nobody) Summary: Error starting JBoss 3.1.0 (alpha) Initial Comment: I get the following error when starting JBoss 3.1.0 (alpha) on Windows 2000 SP2. 15:40:02,269 ERROR [JCAManagedConnectionFactory] Could not create JSR-77 JCAManagedConnectionFactory: null RuntimeMBeanException: org.jboss.management.j2ee.JCAManagedConnectionFactory constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateEx ceptions(MBeanServerImpl.java:828) at org.jboss.mx.server.MBeanServerImpl.instantiate (MBeanServerImpl.java:790) at org.jboss.mx.server.MBeanServerImpl.instantiate (MBeanServerImpl.java:212) at org.jboss.mx.server.MBeanServerImpl.createMBean (MBeanServerImpl.java:253) at org.jboss.management.j2ee.JCAManagedConnectionFactory.c reate(JCAManagedConnectionFactory.java:117) at org.jboss.resource.connectionmanager.BaseConnectionMana ger2.createService(BaseConnectionManager2.java:255) at org.jboss.system.ServiceMBeanSupport.create (ServiceMBeanSupport.java:134) at sun.reflect.GeneratedMethodAccessor15.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create (ServiceController.java:271) at org.jboss.system.ServiceController.create (ServiceController.java:211) at org.jboss.system.ServiceController.create (ServiceController.java:283) at org.jboss.system.ServiceController.create (ServiceController.java:211) at org.jboss.system.ServiceController.create (ServiceController.java:283) at org.jboss.system.ServiceController.create (ServiceController.java:211) at sun.reflect.GeneratedMethodAccessor4.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy10.create(Unknown Source) at org.jboss.resource.RARDeployer.create (RARDeployer.java:181) at org.jboss.deployment.MainDeployer.create (MainDeployer.java:649) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:524) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:488) at sun.reflect.GeneratedMethodAccessor12.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deplo y(URLDeploymentScanner.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanD irectory(URLDeploymentScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan (URLDeploymentScanner.java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner. startService(AbstractDeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:162) at sun.reflect.GeneratedMethodAccessor7.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:341)
[JBoss-dev] [ jboss-Bugs-548628 ] Error starting JBoss 3.1.0 (alpha)
Bugs item #548628, was opened at 2002-04-25 14:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548628group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Theo Harper (btharper) Assigned to: David Jencks (d_jencks) Summary: Error starting JBoss 3.1.0 (alpha) Initial Comment: I get the following error when starting JBoss 3.1.0 (alpha) on Windows 2000 SP2. 15:40:02,269 ERROR [JCAManagedConnectionFactory] Could not create JSR-77 JCAManagedConnectionFactory: null RuntimeMBeanException: org.jboss.management.j2ee.JCAManagedConnectionFactory constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateEx ceptions(MBeanServerImpl.java:828) at org.jboss.mx.server.MBeanServerImpl.instantiate (MBeanServerImpl.java:790) at org.jboss.mx.server.MBeanServerImpl.instantiate (MBeanServerImpl.java:212) at org.jboss.mx.server.MBeanServerImpl.createMBean (MBeanServerImpl.java:253) at org.jboss.management.j2ee.JCAManagedConnectionFactory.c reate(JCAManagedConnectionFactory.java:117) at org.jboss.resource.connectionmanager.BaseConnectionMana ger2.createService(BaseConnectionManager2.java:255) at org.jboss.system.ServiceMBeanSupport.create (ServiceMBeanSupport.java:134) at sun.reflect.GeneratedMethodAccessor15.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create (ServiceController.java:271) at org.jboss.system.ServiceController.create (ServiceController.java:211) at org.jboss.system.ServiceController.create (ServiceController.java:283) at org.jboss.system.ServiceController.create (ServiceController.java:211) at org.jboss.system.ServiceController.create (ServiceController.java:283) at org.jboss.system.ServiceController.create (ServiceController.java:211) at sun.reflect.GeneratedMethodAccessor4.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy10.create(Unknown Source) at org.jboss.resource.RARDeployer.create (RARDeployer.java:181) at org.jboss.deployment.MainDeployer.create (MainDeployer.java:649) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:524) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:488) at sun.reflect.GeneratedMethodAccessor12.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deplo y(URLDeploymentScanner.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanD irectory(URLDeploymentScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan (URLDeploymentScanner.java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner. startService(AbstractDeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:162) at sun.reflect.GeneratedMethodAccessor7.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:341)
[JBoss-dev] [ jboss-Bugs-548628 ] Error starting JBoss 3.1.0 (alpha)
Bugs item #548628, was opened at 2002-04-25 14:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548628group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Theo Harper (btharper) Assigned to: David Jencks (d_jencks) Summary: Error starting JBoss 3.1.0 (alpha) Initial Comment: I get the following error when starting JBoss 3.1.0 (alpha) on Windows 2000 SP2. 15:40:02,269 ERROR [JCAManagedConnectionFactory] Could not create JSR-77 JCAManagedConnectionFactory: null RuntimeMBeanException: org.jboss.management.j2ee.JCAManagedConnectionFactory constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateEx ceptions(MBeanServerImpl.java:828) at org.jboss.mx.server.MBeanServerImpl.instantiate (MBeanServerImpl.java:790) at org.jboss.mx.server.MBeanServerImpl.instantiate (MBeanServerImpl.java:212) at org.jboss.mx.server.MBeanServerImpl.createMBean (MBeanServerImpl.java:253) at org.jboss.management.j2ee.JCAManagedConnectionFactory.c reate(JCAManagedConnectionFactory.java:117) at org.jboss.resource.connectionmanager.BaseConnectionMana ger2.createService(BaseConnectionManager2.java:255) at org.jboss.system.ServiceMBeanSupport.create (ServiceMBeanSupport.java:134) at sun.reflect.GeneratedMethodAccessor15.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create (ServiceController.java:271) at org.jboss.system.ServiceController.create (ServiceController.java:211) at org.jboss.system.ServiceController.create (ServiceController.java:283) at org.jboss.system.ServiceController.create (ServiceController.java:211) at org.jboss.system.ServiceController.create (ServiceController.java:283) at org.jboss.system.ServiceController.create (ServiceController.java:211) at sun.reflect.GeneratedMethodAccessor4.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy10.create(Unknown Source) at org.jboss.resource.RARDeployer.create (RARDeployer.java:181) at org.jboss.deployment.MainDeployer.create (MainDeployer.java:649) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:524) at org.jboss.deployment.MainDeployer.deploy (MainDeployer.java:488) at sun.reflect.GeneratedMethodAccessor12.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deplo y(URLDeploymentScanner.java:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanD irectory(URLDeploymentScanner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan (URLDeploymentScanner.java:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner. startService(AbstractDeploymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start (ServiceMBeanSupport.java:162) at sun.reflect.GeneratedMethodAccessor7.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke (ServiceController.java:867) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start (ServiceController.java:341)
[JBoss-dev] [ jboss-Bugs-548668 ] 3RC1-catalina invokeHome/classload prob
Bugs item #548668, was opened at 2002-04-25 10:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 Category: CatalinaBundle Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: 3RC1-catalina invokeHome/classload prob Initial Comment: Operating System: RedHat Linux 7.1, kernel 2.4.31-i386, windows, others. JDK Version: 1.3.1_03, others There is a problem with jboss-3.0.0RC1_tomcat-4.0.3 where including the home and remote (or local-home and local) EJB interfaces in the WAR file causes a NPE during StatelessSessionContainer$ContainerInterceptor.invokeHome. Removing the EJB interfaces from the WAR file causes the problem to dissappear. Not sure if this is a JBoss unified classloader problem or a catalina servlet 2.3 classloader problem, or a mix. This problem does not happen with JBoss2.4 + catalina. *Lots* of people have complained about this on the email lists under different subject titles, but here is a link to one as an example, which also includes a stack trace: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg15351.html This bug is a killer for people who need to keep their application bundles cross-appserver compatible. Thanks! David -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548678 ] wrong default logdir for tomcat4 in 3rc1
Bugs item #548678, was opened at 2002-04-25 10:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548678group_id=22866 Category: CatalinaBundle Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: wrong default logdir for tomcat4 in 3rc1 Initial Comment: I don't know the ins-and-outs of creating a change request, but was wondering if for the next rc of jboss3-tomcat4 the tomcat4-service.xml file could be changed in this way: From this: Valve className = org.apache.catalina.valves.AccessLogValve prefix = localhost_access suffix = .log pattern = common directory = ../jboss/log / To this: Valve className = org.apache.catalina.valves.AccessLogValve prefix = localhost_access suffix = .log pattern = common directory = ../server/default/log / Currently it assumes the old JBoss-2.4.x-Tomcat-x.x.x dir structure where jboss and tomcat/catalina were next to eachother as subdirs, which isn't the case anymore. Thanx! David -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548678group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548678 ] wrong default logdir for tomcat4 in 3rc1
Bugs item #548678, was opened at 2002-04-25 08:58 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548678group_id=22866 Category: CatalinaBundle Group: CVS HEAD Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: wrong default logdir for tomcat4 in 3rc1 Initial Comment: I don't know the ins-and-outs of creating a change request, but was wondering if for the next rc of jboss3-tomcat4 the tomcat4-service.xml file could be changed in this way: From this: Valve className = org.apache.catalina.valves.AccessLogValve prefix = localhost_access suffix = .log pattern = common directory = ../jboss/log / To this: Valve className = org.apache.catalina.valves.AccessLogValve prefix = localhost_access suffix = .log pattern = common directory = ../server/default/log / Currently it assumes the old JBoss-2.4.x-Tomcat-x.x.x dir structure where jboss and tomcat/catalina were next to eachother as subdirs, which isn't the case anymore. Thanx! David -- Comment By: Scott M Stark (starksm) Date: 2002-04-25 09:06 Message: Logged In: YES user_id=175228 Fixed in RC2 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548678group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548668 ] 3RC1-catalina invokeHome/classload prob
Bugs item #548668, was opened at 2002-04-25 10:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 Category: CatalinaBundle Group: CVS HEAD Status: Open Resolution: None Priority: 7 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: 3RC1-catalina invokeHome/classload prob Initial Comment: Operating System: RedHat Linux 7.1, kernel 2.4.31-i386, windows, others. JDK Version: 1.3.1_03, others There is a problem with jboss-3.0.0RC1_tomcat-4.0.3 where including the home and remote (or local-home and local) EJB interfaces in the WAR file causes a NPE during StatelessSessionContainer$ContainerInterceptor.invokeHome. Removing the EJB interfaces from the WAR file causes the problem to dissappear. Not sure if this is a JBoss unified classloader problem or a catalina servlet 2.3 classloader problem, or a mix. This problem does not happen with JBoss2.4 + catalina. *Lots* of people have complained about this on the email lists under different subject titles, but here is a link to one as an example, which also includes a stack trace: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg15351.html This bug is a killer for people who need to keep their application bundles cross-appserver compatible. Thanks! David -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-548704 ] UnifiedClassLoader safeguards
Patches item #548704, was opened at 2002-04-25 19:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=548704group_id=22866 Category: JBossMX Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Christian Riege (lqd) Assigned to: marc fleury (mnf999) Summary: UnifiedClassLoader safeguards Initial Comment: see attached patch which safeguards UCL against some NullPointer Exceptions (got these while taking it for a spin today). didn't want to commit these myself; UCL is out of my scope i think ;). -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376687aid=548704group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-548668 ] 3RC1-catalina invokeHome/classload prob
Bugs item #548668, was opened at 2002-04-25 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 Category: CatalinaBundle Group: CVS HEAD Status: Pending Resolution: Accepted Priority: 7 Submitted By: David Ward (dward2) Assigned to: Scott M Stark (starksm) Summary: 3RC1-catalina invokeHome/classload prob Initial Comment: Operating System: RedHat Linux 7.1, kernel 2.4.31-i386, windows, others. JDK Version: 1.3.1_03, others There is a problem with jboss-3.0.0RC1_tomcat-4.0.3 where including the home and remote (or local-home and local) EJB interfaces in the WAR file causes a NPE during StatelessSessionContainer$ContainerInterceptor.invokeHome. Removing the EJB interfaces from the WAR file causes the problem to dissappear. Not sure if this is a JBoss unified classloader problem or a catalina servlet 2.3 classloader problem, or a mix. This problem does not happen with JBoss2.4 + catalina. *Lots* of people have complained about this on the email lists under different subject titles, but here is a link to one as an example, which also includes a stack trace: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg15351.html This bug is a killer for people who need to keep their application bundles cross-appserver compatible. Thanks! David -- Comment By: Scott M Stark (starksm) Date: 2002-04-25 11:59 Message: Logged In: YES user_id=175228 Only the NPE is a bug. When fixed this will result in a ClassCastException due to the default optimization of servlet to ejb call and the fact that duplicate classes are included in the ear, and the servlet 2.3 class loading model which will load the war level classes before those visible to the web context parent class loader. In 3.0 the behavior of downgrading a call to use serialization when incompatibles classes where seen was dropped. It would be a request for enhancement to or a seperate bug to restore this behavior. It is not a violation of any j2ee spec to not include the ejb interfaces in the war. The 1.3 j2eeri will deploy such an ear that includes a jsp page calling an ejb. The 1.3 j2eeri will also deploy a war that does include the ejb interfaces in the war. Compatability with such a packaging should be supported. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=548668group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss JMS RA + SwiftMQ + Possible Problems
On Wed, 24 Apr 2002, Anatoly Akkerman wrote: It is a big and complex beast. I remember digging through it when I found some bugs, shrug ... It implements all the CORBA JTA stuff for distributed TXs. I just wrote a hack to propagate the transaction context together with JBoss MethodInvocation, instead of CORBA ORB -- the way Tyrex would do it. Do you reckon how difficult it would be to use Tyrex together with JBoss/IIOP and do transaction propagation the CORBA way? Best, Francisco ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] (no subject)
I am contacting you with the hope that you will be of great assistance to me, I currently have within my reach the sum of 25million US. dollars cash which I intend to use for investment purposes in your company. This money came as a result of a payback contract deal between my husband and a Russain firm in our country's multi-billion dollar Ajaokuta steel plant. The Russain partners returned my husbands share being the above sum after his death. Presently, the new civilian Government has intensified their probe into my husbands financial resources which has led to the freezing of all our accounts, local and foreign, the revoking of all our business licences and the arrest of my first son. In veiw of this I acted very fast to withdraw this money from one of our finance houses before it was closed down. I have deposited the money in a security company with the help of very loyal officials of my late husband. No record is know about this fund by the government because there is no decumentation showing that we received such funds. Due to the current situation in the country and government attitude to my family, I cannot make use of this money within, thus I seek your help in transfering this fund out of the sub African region. Bearing in mind that you may assist me, I have decided to part with 20% of the total sum. Your URGENT response is needed. All correspondance must be through email addresses:[EMAIL PROTECTED] for confidentiality. All correspondence is for the attention of my counsel:Barrister Desmond Opa. Please include your personal phone and Fax number. Regards, JOACHIM SAVIMBE. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 3RC1-catalina invokeHome/classload prob
There's been a lot of back and forth under different subject names on this, so I thought I'd submit a sourceforge bug to make it official: http://sourceforge.net/tracker/index.php?func=detailaid=548668group_id=22866atid=376685 Thanks! David ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-508053 ] table creation fails, deploy succeeds
Bugs item #508053, was opened at 2002-01-24 10:31 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=508053group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Georg Schmid (giorgio42) Assigned to: Dain Sundstrom (dsundstrom) Summary: table creation fails, deploy succeeds Initial Comment: RH 3.0 (200200105), W2K, JDK1.3.1_02, Oracle8.1.7 Even if a create table throws an exception during deployment of an entity bean (for instance, because the same column name appears twice in the corresponding jbosscmp-jdbc.xml definition) as can be seen in the debug log, the deployer continues and finally reports Created table xxx successfully and the deployment succeeds. The transaction is rolled back, but otherwise the exception is ignored. Naturally enough, creating instances of the corresponding entity bean fails with table or view does not exist later on: 2002-01-24 17:30:42,864 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.MaintenanceTriggerEB] Executing SQL: CREATE TABLE MAINTENANCE_TRIGGER (ID VARCHAR2(16), TYPE VARCHAR2(16), UNIT VARCHAR2(16), VALUE VARCHAR2(16), LEVEL VARCHAR2(16), CONSTRAINT pk_MAINTENANCE_TRIGGER PRIMARY KEY (ID)) 2002-01-24 17:30:42,864 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.MaintenanceTriggerEB] Could not create table MAINTENANCE_TRIGGER java.sql.SQLException: ORA-00904: invalid column name at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405) at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822) at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1446) at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900) at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:693) at org.jboss.resource.adapter.jdbc.local.StatementInPool.executeUpdate(StatementInPool.java:736) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartCommand.java:154) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.java:78) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:303) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:175) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:341) at org.jboss.ejb.Application.start(Application.java:219) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:389) at org.jboss.ejb.ContainerFactory.deploy(ContainerFactory.java:312) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.J2eeDeployer.startModules(J2eeDeployer.java:468) at org.jboss.deployment.J2eeDeployer.startApplication(J2eeDeployer.java:439) at org.jboss.deployment.J2eeDeployer.deploy(J2eeDeployer.java:203) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) at org.jboss.deployment.AutoDeployer.deploy(AutoDeployer.java:681) at org.jboss.deployment.AutoDeployer.run(AutoDeployer.java:325) at java.lang.Thread.run(Unknown Source) 2002-01-24 17:30:42,864 DEBUG [org.jboss.tm.TxCapsule] rollback(): Entered, tx=XidImpl [FormatId=257, GlobalId=cna0796942//30, BranchQual=] status=STATUS_ACTIVE 2002-01-24 17:30:42,864 DEBUG [org.jboss.tm.TxManager] rolled back tx: TransactionImpl:XidImpl [FormatId=257, GlobalId=cna0796942//30, BranchQual=] 2002-01-24 17:30:42,864 INFO [org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.MaintenanceTriggerEB] Created table 'MAINTENANCE_TRIGGER' successfully. -- Comment By: Charles Bradley (cbradley2) Date: 2002-04-25 16:11 Message: Logged In: YES user_id=479872 Am I missing something, or is there a way to know which version of JBoss will have this fix? Is there a workaround? Thanks! -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-01-28 12:56 Message: Logged In: YES user_id=251431 JDBCStartCommand will now throw a Deployment exception if an exception occures while creating a table or adding a foreign key constraint. -- You can
[JBoss-dev] Still can't access forums
Hi all, I still can't get access to the forums anymore (user luke_t). I've tried resetting my password 3 times but never receive the reset token email, even though it claims to have sent it. It definately had a valid emali address too because I used to get direct emails from people asking for help with stuff until I changed it to make the address private. It was working fine up until recently but seems to be screwed now. Any ideas? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 26-April-2002
Number of tests run: 571 Successful tests: 554 Errors:4 Failures: 13 [time of test: 26 April 2002 0:54 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20010626 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Still can't access forums
I show that your email address for this user is [EMAIL PROTECTED], is this still correct? It would be best to let the automatic reset fluff be used to change your password... but I can set it if that does not work. Let me know about your email address. --jason Luke Taylor wrote: Hi all, I still can't get access to the forums anymore (user luke_t). I've tried resetting my password 3 times but never receive the reset token email, even though it claims to have sent it. It definately had a valid emali address too because I used to get direct emails from people asking for help with stuff until I changed it to make the address private. It was working fine up until recently but seems to be screwed now. Any ideas? Luke. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 26-April-2002
Number of tests run: 578 Successful tests: 562 Errors:2 Failures: 14 [time of test: 26 April 2002 1:42 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20020124 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 26-April-2002
Number of tests run: 578 Successful tests: 567 Errors:10 Failures: 1 [time of test: 26 April 2002 2:39 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_native for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Optimizations, packaging and the servlet 2.3 class loading model
Our default optimization of ejb calls through the remote interface is not working with the servlet 2.3 container class loading model that advocates: servlet-2.3-spec SRV.9.7.2 Web Application Classloader The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource. It must not allow theWAR to override J2SE or Java servlet API classes. It is further recommended that the loader not allow servlets in theWAR access to the web container's implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. /servlet-2.3-spec When combined with this example ear structure given in the j2ee 1.3 spec: app3.ear: META-INF/application.xml ejb1_client.jar ejb3.jar Class-Path: ejb1_client.jar webapp.war webapp.war: WEB-INF/web.xml WEB-INF/servlets/servlet1.jar Class-Path: ../client_views/ejb1_client.jar WEB-INF/client_views/ejb1_client.jar Calls from a servlet to an ejb through the remote interface fail due to two class loaders having loaded the ejb remote interface class. The recent change to not serialize objects bound into JNDI inside of the server also shows the same problem as the class loader in effect when the homes are bound does not match the class loader of the servlet. We can deal with this by either 1. ignore the servlet 2.3 class loading model, which is what Jetty does by default 2. transform an ear deployment into a canonical representation where the war classes are promoted to an ear level class loader 3. advocate our own packaging model and claim that the vagaries of the specs allow for this as an aspect of deployment 4. revert back to trying to perform marshalling of incompatible classes at runtime based on the caller/callee views What do we want to do? Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 26-April-2002
Number of tests run: 578 Successful tests: 571 Errors:3 Failures: 4 [time of test: 26 April 2002 3:55 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] java.io.EOFException
Hi I am getting one error in my application which is running in JBoss-2.4.4_Tomcat-3.2.3 and MySql as the database. I have highlighted the error below. Can anyone give some idea regarding this error. Thanks a lot in advance Mahesh [2002-04-24 18:22:16,058; JAWSPersistenceManager]Thread-30 findByUserName command executing: SELECT USER_ID FROM CLIENT_USERS WHERE USERNAME=? [2002-04-24 18:22:16,058; JAWSPersistenceManager]Thread-30 Set parameter: idx=1, jdbcType=VARCHAR, value=romit.d.misra [2002-04-24 18:22:16,063; JAWSPersistenceManager]Thread-30 findByUserName command executing: SELECT USER_ID FROM CLIENT_USERS WHERE USERNAME=? [2002-04-24 18:22:16,063; JAWSPersistenceManager]Thread-30 Set parameter: idx=1, jdbcType=VARCHAR, value=erin.m.ivers [2002-04-24 18:22:16,064; PunchOutSessionManagerSB]Thread-30 requester parent exists, parentId = 1018395653613:10.2.36.84:6001 [2002-04-24 18:22:16,064; JAWSPersistenceManager]Thread-30 findByUserName command executing: SELECT USER_ID FROM CLIENT_USERS WHERE USERNAME=? [2002-04-24 18:22:16,064; JAWSPersistenceManager]Thread-30 Set parameter: idx=1, jdbcType=VARCHAR, value=romit.d.misra [2002-04-24 18:22:16,065; PunchOutSessionManagerSB]Thread-30 -- Request Owner found! [2002-04-24 18:22:16,075; JAWSPersistenceManager]Thread-30 findByPermissionBlockId command executing: SELECT REF_PERMISSION_BLOCK_ID FROM REF_PERMISSION_BLOCKS WHERE BLOCK_ID=? [2002-04-24 18:22:16,075; JAWSPersistenceManager]Thread-30 Set parameter: idx=1, jdbcType=VARCHAR, value=6 [2002-04-24 18:22:16,085; JAWSPersistenceManager]Thread-30 Create, id is 1019672536085:10.2.36.84:6001 [2002-04-24 18:22:16,086; JAWSPersistenceManager]Thread-30 Exists command executing: SELECT COUNT(*) FROM PUNCHOUT_SESSIONS WHERE SESSION_ID=? [2002-04-24 18:22:16,086; JAWSPersistenceManager]Thread-30 Set parameter: idx=1, jdbcType=VARCHAR, value=1019672536085:10.2.36.84:6001 [2002-04-24 18:22:16,086; JAWSPersistenceManager]Thread-30 Create command executing: INSERT INTO PUNCHOUT_SESSIONS (IS_LAST_APPROVER,SESSION_ID,PO_USER_ROLE,BUYER_REQ_NUMBER,SHARED_SECRET,CREATION_DATE,REQUESTER_ID,PUNCHOUT_TYPE,BROWSER_FORM_POST,BUYER_COOKIE,PO_USER_ID,NETWORK_ID) VALUES (?,?,?,?,?,?,?,?,?,?,?,?) [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=1, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=2, jdbcType=VARCHAR, value=1019672536085:10.2.36.84:6001 [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=3, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=4, jdbcType=VARCHAR, value=PR49232 [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=5, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=6, jdbcType=TIMESTAMP, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=7, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=8, jdbcType=VARCHAR, value=INSPECT [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=9, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=10, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=11, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,087; JAWSPersistenceManager]Thread-30 Set parameter: idx=12, jdbcType=VARCHAR, value=NULL [2002-04-24 18:22:16,088; JAWSPersistenceManager]Thread-30 Rows affected = 1 [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Store command executing: UPDATE PUNCHOUT_SESSIONS SET IS_LAST_APPROVER=?,PO_USER_ROLE=?,SHARED_SECRET=?,CREATION_DATE=?,REQUESTER_ID=?,BROWSER_FORM_POST=?,BUYER_COOKIE=?,PO_USER_ID=?,NETWORK_ID=? WHERE SESSION_ID=? [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=1, jdbcType=VARCHAR, value=false [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=2, jdbcType=VARCHAR, value=Requester [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=3, jdbcType=VARCHAR, value=YCDjrodpOAA= [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=4, jdbcType=TIMESTAMP, value=2002-04-24 18:22:16.089 [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=5, jdbcType=VARCHAR, value=1018395653620:10.2.36.84:6001 [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=6, jdbcType=VARCHAR, value=https://service.ariba.com/punchout?ansessionid=1868187 [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=7, jdbcType=VARCHAR, value=1868187 [2002-04-24 18:22:16,090; JAWSPersistenceManager]Thread-30 Set parameter: idx=8, jdbcType=VARCHAR,
[JBoss-dev] Automated JBoss Testsuite Results: 26-April-2002
Number of tests run: 578 Successful tests: 571 Errors:3 Failures: 4 [time of test: 26 April 2002 3:55 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Server VM (build 1.3.1-b24, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [jmxdoclet] [jmxdoclet] Another exception has been detected while we were handling last error. [jmxdoclet] Generating output for 'org.jboss.test.jmx.mbean.TestMBClassLoader' using template file 'jar:file:/disk/orig/home/lubega/jbossro/jboss-all/tools/lib/xdoclet.jar!/xdoclet/jmx/mbean.j'. [jmxdoclet] No information available. [jmxdoclet] Please check ERROR REPORT FILE for further information, if there is any. [jmxdoclet] Good bye. [jmxdoclet] [jmxdoclet] [jmxdoclet] [jmxdoclet] Another exception has been detected while we were handling last error. [jmxdoclet] Dumping information about last error: [jmxdoclet] ERROR REPORT FILE = (N/A) [jmxdoclet] PC= 0x0x402420e5 [jmxdoclet] SIGNAL= 11 [jmxdoclet] FUNCTION NAME = (N/A) [jmxdoclet] LIBRARY NAME = (N/A) [jmxdoclet] Please check ERROR REPORT FILE for further information, if there is any. [jmxdoclet] Good bye. [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/testsuite/build.xml:601: Java returned: 134 [execmodules] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:90) [execmodules] at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:175) [execmodules] at xdoclet.DocletTask.execute(DocletTask.java:298) [execmodules] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) [execmodules] at org.apache.tools.ant.Task.perform(Task.java:217) [execmodules] at org.apache.tools.ant.Target.execute(Target.java:164) [execmodules] at org.apache.tools.ant.Target.performTasks(Target.java:182) [execmodules] at org.apache.tools.ant.Project.executeTarget(Project.java:601) [execmodules] at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:256) [execmodules] at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:120) [execmodules] at org.apache.tools.ant.Task.perform(Task.java:217) [execmodules] at org.apache.tools.ant.Target.execute(Target.java:164) [execmodules] at org.apache.tools.ant.Target.performTasks(Target.java:182) [execmodules] at org.apache.tools.ant.Project.executeTarget(Project.java:601) [execmodules] at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) [execmodules] at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:269) [execmodules] at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:184) [execmodules] at org.apache.tools.ant.Task.perform(Task.java:217) [execmodules] at org.apache.tools.ant.Target.execute(Target.java:164) [execmodules] at org.apache.tools.ant.Target.performTasks(Target.java:182) [execmodules] at org.apache.tools.ant.Project.executeTarget(Project.java:601) [execmodules] at org.apache.tools.ant.Project.executeTargets(Project.java:560) [execmodules] at org.apache.tools.ant.Main.runBuild(Main.java:454) [execmodules] at org.apache.tools.ant.Main.start(Main.java:153) [execmodules] at org.apache.tools.ant.Main.main(Main.java:176) BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/testsuite/build.xml:601: Java returned: 134 Total time: 1 minute 4 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 26-April-2002
Number of tests run: 578 Successful tests: 564 Errors:10 Failures: 4 [time of test: 26 April 2002 5:49 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_02 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 26-April-2002
Number of tests run: 578 Successful tests: 567 Errors:10 Failures: 1 [time of test: 26 April 2002 6:46 GMT] [java.version: 1.4.0] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.0-b92] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_j2sdk140 for details of this test. See http://lubega.com for general test information. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. Remember - if a test becomes broken after your changes - fix it or fix the test! Oh dear - still got some errors! Thanks for all your effort - we really do love you! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JL] Is it time for a new enterprise solution?
Critique on JBoss configuration. http://www.javalobby.org/thread.jsp?forum=61thread=3254 -- Juha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-529880 ] TCat 4.0.2: auth does not work, Jetty OK
Bugs item #529880, was opened at 2002-03-14 14:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=529880group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Mike Finn (mikefinn) Assigned to: Scott M Stark (starksm) Summary: TCat 4.0.2: auth does not work, Jetty OK Initial Comment: Form based authentication does not appear to work in embedded Tomcat, but does with Jetty. OS: Win NT JVM: 1.3.01 JBoss: 3.0 Beta distros from SF (Jetty and Tomcat). I have a web app that uses FORM based authentication. jboss-web.xml and auth.conf are set up to use UserRolesLoginModule. In both Jetty and Tomcat builds, when I deploy the app in Jetty and attempt to access a protected resource, I get my login form. When I log in to the Jetty instance with the correct user/password, I get the requested (protected) page. When I do the same with Tomcat, I get a 403/access denied error page (NOT my form-error- page). Both Jetty and Tomcat instances have the same auth.conf, user.properties, and roles.properties files. I also tested this with standalone Tomcat 4.0.2 (which uses a tomcat-user file that has the same user/password/roles as JBoss/Tomcat|Jetty. This configuration works. Mike -- Comment By: Maurice Schoenmakers (maurice_s) Date: 2002-04-26 08:14 Message: Logged In: YES user_id=526908 Well after a wile of debugging, i figured out that the problemm is caused by different org.jboss.security.SecurityAssociation classes. The current embedded catalina code sets a single JBossSecurityMgrRealm for all deployed web apps. After authentication the principal credential information is set globally using statics in the class org.jboss.security.SecurityAssociation. (to transfer it to the server(easy for sniffers?! ) Unfortunately there are multiple org.jboss.security.SecurityAssociation Classes available: The current code sets the information in the class of the global lib/jbosssx.jar, because the JBossSecurityMgrRealm does not use the correct ClassLoader. Each Web app has an own org.jboss.security.SecurityAssociation Class wich is not accessed by the JBossSecurityMgrRealm (If you include the client jars in your war file). Thus the principalcredential information is never set in the correct class and thus never transferred to the server. After changing the embedding code to set a new JBossSecurityMgrRealm for each deployed WebApp in the contextInit() method things worked fine for me. (I'm not sure how this affects single sign on across multile web apps ? ) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=529880group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
