Re: [JBoss-dev] Does clustering work on OS X?
As in just running the all config, or are you actually clustering with something else? Running all certainly works in 3.2 - I've not tried HEAD in a while. In fact, I've run all on a Mac and linux box together without problems using JDK 1.4.1. Steve Coy On Thursday, April 3, 2003, at 04:32 PM, Dain Sundstrom wrote: Does clustering in jboss-head work for anyone on OS X? Whenever I try to shutdown jboss-head on my powerbook the entire os locks up until I unplug my wireless access point and 'killall -9 java'. This can take like 30 minutes to get my laptop responsive again. [12:27:50] dain$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) -dain --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Looking to do 3.2.0 final next this weekend
Just mail them to me - I'm cleaning this up now. A couple of the
xdoclet todo's must have slipped through my screen.
The xdoclet upgrade was somewhat tedious :-)
Steve Coy
On Tuesday, March 25, 2003, at 09:26 PM, Bernd Koecke wrote:
Hi,
I found three minor bugs in the build.xml-files for the 'all'-target
and there for the generation of the docs:
It seems that the new Xdoclet changed the todo-target. It doesn't
support 'sourcepath' and 'classpathref'. After commenting these out in
common/build.xml and system/build.xml all works fine.
The third is in connector/build.xml in target 'docs-javadocs'. I
changed 'sourcepath' from '${source.java}' to '${build.gen-src}'.
These bugs are in no way show stoppers, but should I send diffs for
them and how?
My environment is:
jboss-3.2 from cvs with Branch_3_2 on Linux and sun-jdk-1.4.1_02.
Regards
Bernd
Scott M Stark wrote:
I'm looking to do the 3.2.0 final release this weekend so please try
to clean
up any outstanding bugs in your areas by then. I'll start putting the
release
together on the 30th and finalize it something on the 31st barring any
major problems.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
--
Dipl.-Inform. Bernd Koecke
UNIX-Entwicklung
Schlund+Partner AG
Fon: +49-721-91374-0
E-Mail: [EMAIL PROTECTED]
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Looking to do 3.2.0 final next this weekend
On Tuesday, March 25, 2003, at 09:26 PM, Bernd Koecke wrote:
The third is in connector/build.xml in target 'docs-javadocs'. I
changed 'sourcepath' from '${source.java}' to '${build.gen-src}'.
Why did you need to do this?
Running
[EMAIL PROTECTED] connector]$ ./build.sh docs
works fine for me.
Steve Coy
---
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Have you tried the equivalent of this sort of thing in your script? [EMAIL PROTECTED] jboss-3.2]$ ANT_OPTS=-Xmx256M build/build.sh Steve Coy On Wednesday, March 26, 2003, at 01:11 AM, Chris Kimpton wrote: --- Chris Kimpton [EMAIL PROTECTED] wrote: Hi, Does anyone get problems compiling HEAD on Linux - Caused by: java.lang.OutOfMemoryError Within the doclet stuff... This seems to be my problem - since I can compile it manually outside of my scripts... but all they do is one shell script calls another script which calls build.sh... Is there some default sh memory limits that are limiting things? I will look at getting a windows version running and probably re-writing my scripts since they are getting out of hand... But basically - the regular compiles are currently stopped! Chris --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: AW: [JBoss-dev] jboss.net xdoclet subtask
Sorry about that. I sent the message twice, because the first attempt did not show up. If you look at the date of the second one, you will see that it was sent about 8 hours before the first one. It eventually arrived about 28 hours after I sent it. I have no idea what it was doing in the meantime. So, I did see your response - to the second message that arrived first :-) Steve Coy On Monday, March 24, 2003, at 07:45 PM, Jung , Dr. Christoph wrote: Are you a mail-list-bot or what? If that is the case, you seem to be able to do useful programming in your sparetime ;-) But your parsing subsystem seems not to cope with non-native English emails ... As written in a separate response to your first of the three equivalent emails a week ago (and as should be apparent from CVS), I removed all that jboss-net specific 1.2 stuff from the 3_2 branch and updated to the official xdoclet stuff. The stuff is used by the jboss.net testsuite (and some web-service end-users out there). CGJ -Ursprüngliche Nachricht- Von: Stephen Coy [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 20. März 2003 23:45 An: [EMAIL PROTECTED] Betreff: [JBoss-dev] jboss.net xdoclet subtask Hi, Is it reasonable to assume that the jboss.net xdoclet subtask that was being worked on nearly a year ago is currently not used in anger anywhere? I can see a couple of flavours of the code (in org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in Branch_3_2, but I can't see any actual uses of it in build files. Th reason I ask is that I'm currently migrating Branch_3_2 to xdoclet 1.2, and I'm not sure what to do with the jboss.net stuff. Steve Coy --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss.net xdoclet subtask
Hi, Is it reasonable to assume that the jboss.net xdoclet subtask that was being worked on nearly a year ago is currently not used in anger anywhere? I can see a couple of flavours of the code (in org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in Branch_3_2, but I can't see any actual uses of it in build files. Th reason I ask is that I'm currently migrating Branch_3_2 to xdoclet 1.2, and I'm not sure what to do with the jboss.net stuff. Steve Coy --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Branch_3_2 has been updated to xdoclet 1.2
I've updated the build.xml files to use xdoclet 1.2 (pre b3). It has the same jars as HEAD, although with correspondingly different names. I suspect that we should change these at some point to include version info like a lot of the other jars. i will tackle Branch_3_0 next, unless anyone has objections. Note that this means an ant upgrade to 1.5.x is required. Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss.net xdoclet subtask
Hi, Is it reasonable to assume that the jboss.net xdoclet subtask that was being worked on nearly a year ago is currently not used in anger anywhere? I can see a couple of flavours of the code (in org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in Branch_3_2, but I can't see any actual uses of it in build files. Th reason I ask is that I'm currently migrating Branch_3_2 to xdoclet 1.2, and I'm not sure what to do with the jboss.net stuff. Steve Coy --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 21-March-2003
Hi, Have you tried this on any unix boxes recently? Both my Mac and Linux boxes yield over 150 errors using 1.4.1 and over 50 using 1.3.1. I run the all configuration. Most of the errors seem to be deployment related in one way or another. For example, the bank and bankiiop tests fail en mass with bank not bound. I also see this kind of thing a lot: N/A Incomplete Deployment listing: Packages waiting for a deployer: none Incompletely deployed packages: none MBeans waiting for classes: none MBeans waiting for other MBeans: [ObjectName: jboss.j2ee:jndiName=test/TestDataSource,service=EJB state: FAILED I Depend On: Depends On Me: javax.naming.NameNotFoundException: comp not bound] at org.jboss.deployment.MainDeployer.checkIncompleteDeployments(MainDeploye r.java:1152) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:616) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:597) at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDi spatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.jmx.adaptor.rmi.RMIAdaptorImpl.invoke(RMIAdaptorImpl.java:269) at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.ja va:701) at java.lang.Thread.run(Thread.java:554) 2.323 Steve Coy On Saturday, March 22, 2003, at 11:16 AM, [EMAIL PROTECTED] wrote: JBoss daily test results SUMMARY Number of tests run: 1146 Successful tests: 1138 Errors:8 Failures: 0 [time of test: 2003-03-21.23-39 GMT] [java.version: 1.3.1_06] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_06-b01] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-03-21.23-39 for the junit report of this test. 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: StatefulSessionUnitTestCase Test: testInVMSessionHandlePassivation(org.jboss.test.cts.test.StatefulSessio nUnitTestCase) Type:error Exception: java.rmi.NoSuchObjectException Message: Could not activate; failed to restore state; CausedByException is: C:\cvs\JBoss3.2\jboss-3.2\build\output\jboss- 3.2.0RC4\server\all\data\sessions\StatefulSessionBean-ddksxv0q- 4\ddksxxww-b.ser (The system cannot find the file specified) - Suite: PathologicalUnitTestCase Test: testErrorFromRemove(org.jboss.test.entity.test.PathologicalUnitTestCase ) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: DeployServiceUnitTestCase Test: testDDEntityRefs(org.jboss.test.jmx.test.DeployServiceUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: exception in init of file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/entityref.sar; - nested throwable: (org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.NullPointerException)) - Suite: DeployXMBeanUnitTestCase Test: testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: no protocol: META-INF/org/jboss/test/jmx/xmbean/User.xml; - nested throwable: (java.net.MalformedURLException: no protocol: META-INF/org/jboss/test/jmx/xmbean/User.xml)) - Suite: MissingClassUnitTestCase Test:
Re: [JBoss-dev] Possible bug in Log4jAdapterFactory
I was about to send almost the same message. Making this change works for me. I'll check it in soon unless someone beats me to it, because I suspect the culprit is asleep right now. Steve Coy On Thursday, March 20, 2003, at 10:44 PM, Bernd Koecke wrote: Hi, I'm using jboss-3.2 Branch_3_2 from cvs on Linux with Sun jdk 1.4.1_2 and get an error while compiling the jmx module. The class org.jboss.mx.logging.log4j.Log4jAdapterFactory has a public member 'dummy' of type TracePriority. This class is gone after calling the clean target. When I change the member field to 'XPriority dummy = XPriority.TRACE' it compiles and the resulting server works. This happens with a clean checkout too. Do I have a bug in my cvs checkout? And if not, is it the right bugfix or will I get trouble at other places in the server? Thanks, Bernd -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] mime-attachment --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.test.jmx.test.DeployXMBeanUnitTestCase and DTD
It's nearly done - I've been doing a fair amount of sanity checking before I commit it. One thing I noticed is that the test suite has many, many more failures when run under Java 1.4.1, so I've had to rebuild and retest under 1.3.1 to make sure that I haven't broken anything. Steve Coy On Friday, March 21, 2003, at 01:08 AM, Scott M Stark wrote: The jboss_xmbean_1_0.dtd has been updated in 3.2 but xdoclet apparently has not as the org.jboss.test.jmx.test.DeployXMBeanUnitTestCase is failing because of an invalid User.xml that is being generated via xdoclet. Can we synch up the xdoclet binary in 3.2? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The recent OSX 1.4.1/XDoclet problem
It's not you. I should have tested this myself. It's doing the same thing for me too, but you may be right about the fork. You can set JAVA_HOME in an environment wide way by setting it in your ~/.MacOSX/environment.plist file: ?xml version=1.0 encoding=UTF-8?> !DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd> plist version=1.0> dict> key>ANT_HOME/key> string>/Users/steve/tools/apache-ant-1.5.2/string> key>CVS_RSH/key> string>ssh/string> key>JAVA_HOME/key> string>/Library/Java/Home/string> key>MAVEN_HOME/key> string>/Users/steve/tools/maven-1.0-beta-8/string> key>ORACLE_HOME/key> string>/Users/oracle/9iR2/orahome/string> /dict> /plist> The Property List Editor in the Apple Developer tools provides a convenient way to build/edit this file. You need to log out and log back in before it takes effect. It's possible that this may eliminate your problem for now. In the meantime, I'm looking at updating the xdoclet in the 3.0 and 3.2 branches. Steve Coy On Tuesday, March 18, 2003, at 09:22 PM, Lennart Petersson wrote: don't know if it's me being stupid... but this wont help me anyway :( When building with -verbose flag it correctly reports that it has detected a 1.3.1 jvm but then it still craches when it's time for the xdoclet task. Any ideas? Has it anything to do with the fact that it is forking the xdocletXDocletMain? /L tisdagen den 18 mars 2003 kl 01.24 skrev Stephen Coy: Unfortunately, all versions of xdoclet (except the one David J fixed) have the same bug - using InputStream.available() to see how many bytes are left in the file. I'm part way thru getting JBoss 3.0.x to build with Apple's 1.4.1, but I had to migrate HEAD's xdoclet into the source base and fix almost every build.xml to suit. In retrospect, it's probably simpler to get the version of xdoclet from CVS that we've used here (I think David tagged it), fix it, and use that. As has been previously mentioned, you can still build with 1.3.1 by setting: JAVA_HOME= /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home Steve Coy On Tuesday, March 18, 2003, at 01:36 AM, Lennart Petersson wrote: Was Mr. Jenk's fix only for head? Because I get problems when building 3.0/3.2 also. Here is output from 3.0: compile-mbean-sources: [mkdir] Created dir: /Users/lepe/projects/JbossSources/jboss-3.0/common/output/gen-src sourcepath is deprecated. the preferred way to design sources is via nested fileset> Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Running mbeanInterface/> [xdoclet] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/lepe/projects/JbossSources/jboss-3.0/tools/lib/xdoclet.jar!/xdoclet/jmx/mbean.j'. [xdoclet] Running XDoclet failed [xdoclet] Running XDoclet failed.>> [xdoclet] java.lang.RuntimeException: Error running XDoclet [xdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:77) [xdoclet] at xjavadoc.ant.XJavaDocMain.main(XJavaDocMain.java:94) Using OSX jdk 1.4.1 official release and latest 3.0 --- This SF.net email is sponsored by:Crypto Challenge is now open!Get cracking and register here for some mind boggling fun andthe chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Does your code think in ink?You could win a Tablet PC. Get a free Tablet PC hat just for playing.What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] The recent OSX 1.4.1/XDoclet problem
I just got Branch_3_2 to build using this trick and with JAVA_HOME set to /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home rather than the /Library/Java/Home that I have below. On Tuesday, March 18, 2003, at 10:27 PM, Stephen Coy wrote: It's not you. I should have tested this myself. It's doing the same thing for me too, but you may be right about the fork. You can set JAVA_HOME in an environment wide way by setting it in your ~/.MacOSX/environment.plist file: ?xml version=1.0 encoding=UTF-8?> !DOCTYPE plist PUBLIC -//Apple Computer//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd> plist version=1.0> dict> key>ANT_HOME/key> string>/Users/steve/tools/apache-ant-1.5.2/string> key>CVS_RSH/key> string>ssh/string> key>JAVA_HOME/key> string>/Library/Java/Home/string> key>MAVEN_HOME/key> string>/Users/steve/tools/maven-1.0-beta-8/string> key>ORACLE_HOME/key> string>/Users/oracle/9iR2/orahome/string> /dict> /plist> The Property List Editor in the Apple Developer tools provides a convenient way to build/edit this file. You need to log out and log back in before it takes effect. It's possible that this may eliminate your problem for now. In the meantime, I'm looking at updating the xdoclet in the 3.0 and 3.2 branches. Steve Coy On Tuesday, March 18, 2003, at 09:22 PM, Lennart Petersson wrote: don't know if it's me being stupid... but this wont help me anyway :( When building with -verbose flag it correctly reports that it has detected a 1.3.1 jvm but then it still craches when it's time for the xdoclet task. Any ideas? Has it anything to do with the fact that it is forking the xdocletXDocletMain? /L tisdagen den 18 mars 2003 kl 01.24 skrev Stephen Coy: Unfortunately, all versions of xdoclet (except the one David J fixed) have the same bug - using InputStream.available() to see how many bytes are left in the file. I'm part way thru getting JBoss 3.0.x to build with Apple's 1.4.1, but I had to migrate HEAD's xdoclet into the source base and fix almost every build.xml to suit. In retrospect, it's probably simpler to get the version of xdoclet from CVS that we've used here (I think David tagged it), fix it, and use that. As has been previously mentioned, you can still build with 1.3.1 by setting: JAVA_HOME= /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home Steve Coy On Tuesday, March 18, 2003, at 01:36 AM, Lennart Petersson wrote: Was Mr. Jenk's fix only for head? Because I get problems when building 3.0/3.2 also. Here is output from 3.0: compile-mbean-sources: [mkdir] Created dir: /Users/lepe/projects/JbossSources/jboss-3.0/common/output/gen-src sourcepath is deprecated. the preferred way to design sources is via nested fileset> Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Running mbeanInterface/> [xdoclet] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/lepe/projects/JbossSources/jboss-3.0/tools/lib/xdoclet.jar!/xdoclet/jmx/mbean.j'. [xdoclet] Running XDoclet failed [xdoclet] Running XDoclet failed.>> [xdoclet] java.lang.RuntimeException: Error running XDoclet [xdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:77) [xdoclet] at xjavadoc.ant.XJavaDocMain.main(XJavaDocMain.java:94) Using OSX jdk 1.4.1 official release and latest 3.0
Re: [JBoss-dev] The recent OSX 1.4.1/XDoclet problem
Unfortunately, all versions of xdoclet (except the one David J fixed) have the same bug - using InputStream.available() to see how many bytes are left in the file. I'm part way thru getting JBoss 3.0.x to build with Apple's 1.4.1, but I had to migrate HEAD's xdoclet into the source base and fix almost every build.xml to suit. In retrospect, it's probably simpler to get the version of xdoclet from CVS that we've used here (I think David tagged it), fix it, and use that. As has been previously mentioned, you can still build with 1.3.1 by setting: JAVA_HOME= /System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/Home Steve Coy On Tuesday, March 18, 2003, at 01:36 AM, Lennart Petersson wrote: Was Mr. Jenk's fix only for head? Because I get problems when building 3.0/3.2 also. Here is output from 3.0: compile-mbean-sources: [mkdir] Created dir: /Users/lepe/projects/JbossSources/jboss-3.0/common/output/gen-src sourcepath is deprecated. the preferred way to design sources is via nested fileset Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. Forked:true [xdoclet] Running mbeanInterface/ [xdoclet] Generating output for 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template file 'jar:file:/Users/lepe/projects/JbossSources/jboss-3.0/tools/lib/ xdoclet.jar!/xdoclet/jmx/mbean.j'. [xdoclet] Running XDoclet failed [xdoclet] Running XDoclet failed. [xdoclet] java.lang.RuntimeException: Error running XDoclet [xdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:77) [xdoclet] at xjavadoc.ant.XJavaDocMain.main(XJavaDocMain.java:94) Using OSX jdk 1.4.1 official release and latest 3.0 --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Going ahead with EJB module refactor
A clean checkout of jboss-head is now building and running for me on MacOS X and Java 1.4.1. On Friday, March 14, 2003, at 05:41 AM, Dain Sundstrom wrote: So how is it coming? -dain On Wednesday, March 12, 2003, at 06:02 PM, Stephen Coy wrote: The fix certainly allows xdoclet to build itself, whereas it was failing with the same problem we have in JBoss HEAD. I can't check against JBoss HEAD until I get home tonight (its AM here), but I'm a happy camper for my dev work now. Steve Coy On Thursday, March 13, 2003, at 04:15 AM, David Jencks wrote: There's a patch on their bugtracker that is supposed to fix this: http://opensource.atlassian.com/projects/xdoclet/secure/ ViewIssue.jspa?key=XDT-376 They want feedback. I need to keep working so I haven't up(?)graded my 1.4.1 copy yet. david jencks On 2003.03.12 04:53 Jason Dillon wrote: Actually now that I think about it I have to wait until i can actually build the source tree again... Any word from the XDoclet folks on what the problem is? --jason On Wednesday, March 12, 2003, at 03:30 PM, Jason Dillon wrote: Tonight I will be working on the EJB module re-factoring. Will probably have something ready to check in tomorrow. If you have EJB related bits to commit in system please do so now. --jason --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Going ahead with EJB module refactor
The fix certainly allows xdoclet to build itself, whereas it was failing with the same problem we have in JBoss HEAD. I can't check against JBoss HEAD until I get home tonight (its AM here), but I'm a happy camper for my dev work now. Steve Coy On Thursday, March 13, 2003, at 04:15 AM, David Jencks wrote: There's a patch on their bugtracker that is supposed to fix this: http://opensource.atlassian.com/projects/xdoclet/secure/ ViewIssue.jspa?key=XDT-376 They want feedback. I need to keep working so I haven't up(?)graded my 1.4.1 copy yet. david jencks On 2003.03.12 04:53 Jason Dillon wrote: Actually now that I think about it I have to wait until i can actually build the source tree again... Any word from the XDoclet folks on what the problem is? --jason On Wednesday, March 12, 2003, at 03:30 PM, Jason Dillon wrote: Tonight I will be working on the EJB module re-factoring. Will probably have something ready to check in tomorrow. If you have EJB related bits to commit in system please do so now. --jason --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Checking out 3.2 From CVS
I keep this on a Stickies note: JBoss CVS cvs -q -z3 co jboss-head cvs -q -z3 co -r Branch_3_2 jboss-3.2 cvs -q -z3 co -r Branch_3_0 jboss-3.0 cvs -q -z3 co -r Branch_3_0 jboss-all As far as I am aware, the last two are the same. Steve Coy On Thursday, March 13, 2003, at 04:43 PM, Hunter Hillegas wrote: Okay, I give up. I looked all over and I couldn't find the info... How do I check out JBoss 3.2 from CVS? What is the module name? Is there a branch name? Also, is there a page where this info is kept up to date? Thanks, Hunter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Missing method-attributes declaration in jboss_3_0.dtd
Hi, At some point during the evolution of JBoss 3.0.x, support for declaring method-attributes was added into the jboss.xml deployment descriptor. However, the DTD (jboss_3_0.dtd) has not been updated. If someone can confirm that this is just an oversight, I'll fix it up. We just encountered this while trying to migrate from our super-modified xdoclet 1.1.2 to the current xdoclet 1.2. Currently xdoclet 1.2 does not believe that JBoss 3.0.x supports method-attributes, presumably because of the dtd. Thanks, Steve Coy --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] NPE in GlobalTxEntityMap after recent changes
3.2 HEAD contain additional synchronization fixes (courtesy of David Jencks). It smells like this sort of problem, so I'll backport these over the weekend. Steve Coy On Friday, December 6, 2002, at 09:07 AM, Scott M Stark wrote: I'm seeing sporadic NPEs like the following in the GlobalTxEntityMap in the 3.0 branch code. This was recently changed and has introduced some bugs in the tx map management. Please fix this. 13:50:39,843 ERROR [LogInterceptor] TransactionRolledbackException, causedBy: java.lang.NullPointerException at org.jboss.ejb.GlobalTxEntityMap.associate(GlobalTxEntityMap.java:71) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.register(EntityS ynchronizationInterceptor.java:176) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySyn chronizationInterceptor.java:311) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentran ceInterceptor.java:90) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceIn terceptor.java:163) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockIntercepto r.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationIn terceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterc eptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercepto rCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:92) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.ja va:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493) at org.jboss.ejb.Container.invoke(Container.java:712) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java: 102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.ja va:77) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) at org.jboss.proxy.ejb.EntityInterceptor.invoke(EntityInterceptor.java:116 ) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy108.update(Unknown Source) at com.sun.ecperf.mfg.workorderses.ejb.WorkOrderSesEJB.updateWorkOrder(Wor kOrderSesEJB.java:309) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Sta telessSessionContainer.java:660) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Statel essSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterc eptor.java:107) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercepto rCMT.java:228) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:92) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.ja va:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContaine r.java:313) at org.jboss.ejb.Container.invoke(Container.java:712) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:38 2) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460 ) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.j ava:701) at java.lang.Thread.run(Thread.java:479) Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED]
[JBoss-dev] JBoss 3.0 memory profile
Hi, I've attached a memory profile (which your email client may expand inline - it's html) of JBoss in action. This is a picture of our application importing several thousand phone numbers from a text file, which are stored as new entity beans in a single transaction. A NumbersBean has several CMRs, and has a PhoneNumber as a primary key. This is basically to provoke comment, rather than anything particular, such as Wow, look at all those org.jboss.logging.Logger objects - should they be there?. In other words, I thought people would be interested in it, and hopefully there is nothing surprising in there. This is a few days old Branch_3_0 build btw. Steve Coy Title: JBoss 3.x on localhost Class monitor Class monitor Session: JBoss 3.x on localhost Time of export: Thursday, November 28, 2002 3:40:50 PM EST JVM time: 107:19 NameInstance countSize org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge$FieldState29424941568 org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge$FieldState11810566880 org.jboss.logging.Logger7856125696 org.jboss.mx.metadata.AttributeOperationResolver$Node6353203296 org.jboss.ejb.plugins.cmp.jdbc.bridge.RelationSet5663135912 org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge$TxSynchronization566390608 org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler252180672 org.jboss.ejb.EntityEnterpriseContext$EntityContextImpl252160504 org.jboss.ejb.EntityEnterpriseContext2521201680 org.jboss.util.LRUCachePolicy$LRUCacheEntry249099600 org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge$EntityState248939824 org.jboss.ejb.plugins.cmp.jdbc.JDBCContext248939824 com.whitesmiths.sacha.ejb.numbers.interfaces.PhoneNumber248339728 com.whitesmiths.sacha.ejb.numbers.implementations.NumbersBean$Proxy241858032 org.jboss.mx.capability.ReflectedMBeanDispatcher$MethodPair169127056 org.jboss.invocation.InvokerInterceptor156337512 org.jboss.proxy.ClientContainer156325008 org.jboss.invocation.InvocationContext156325008 org.jboss.proxy.SecurityInterceptor156024960 org.jboss.proxy.TransactionInterceptor156024960 org.jboss.ejb.plugins.local.EntityProxy150636144 org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock145581480 org.jboss.ejb.plugins.EntitySynchronizationInterceptor$InstanceSynchronization142234128 org.jboss.proxy.ejb.EntityInterceptor141922704 org.jboss.ejb.GlobalTxEntityMap$GlobalTxEntityMapCleanup141734008 org.jboss.management.j2ee.CountStatistic60929232 org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge49827888 org.jboss.ejb.plugins.cmp.jdbc.JDBCTypeSimple49815936 org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCCMPFieldMetaData49827888 org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCMappingMetaData49011760 org.jboss.resource.connectionmanager.CachedConnectionManager$IdentityWrapper4877792 org.jboss.metadata.MethodMetaData47226432 org.jboss.mx.server.registry.MBeanEntry42813696 org.jboss.ejb.plugins.cmp.jdbc.QueryParameter42213504 org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCFunctionMappingMetaData3809120 org.jboss.invocation.Invocation32613040 org.jboss.mx.capability.ReflectedMBeanDispatcher27913392 org.jboss.mx.metadata.AttributeOperationResolver2794464 org.jboss.management.j2ee.TimeStatistic26823584 org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCAutomaticQueryMetaData2323712 org.jboss.system.ServiceContext2297328 org.jboss.system.ServiceController$ServiceProxy2295496 org.jboss.mq.Subscription2198760 org.jboss.metadata.EjbLocalRefMetaData2106720 org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$EntityMapEntry2054920 org.jboss.mq.SpyXAResource1953120 org.jboss.jms.asf.StdServerSession1957800 org.jboss.mq.SpyMessageConsumer19510920 org.jboss.mq.SpyTopicSession19510920 org.jboss.net.protocol.file.FileURLConnection1868928 org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL1635216 org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge16210368 org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCRelationshipRoleMetaData1629072 org.jboss.metadata.RelationshipRoleMetaData1626480 org.jboss.metadata.MethodAttributes1453480 org.jboss.web.WebClassLoader1369792 org.jboss.ejb.plugins.local.BaseLocalContainerInvoker1365440 org.jboss.resource.connectionmanager.CachedConnectionInterceptor1365440 org.jboss.ejb.plugins.LogInterceptor1364352 org.jboss.ejb.plugins.cmp.jdbc.JDBCFindByPrimaryKeyQuery1346432 org.jboss.proxy.compiler.Proxies$Impl1344288 org.jboss.metadata.QueryMetaData1304160 org.jboss.resource.adapter.jdbc.local.LocalPreparedStatement1293096 org.jboss.security.SimplePrincipal1292064 org.jboss.resource.adapter.jdbc.local.LocalConnection1292064 org.jboss.resource.connectionmanager.ConnectionRecord1293096 org.jboss.ejb.plugins.SecurityInterceptor1193808 org.jboss.ejb.plugins.local.LocalHomeProxy1141824 org.jboss.ejb.plugins.TxInterceptorCMT1143648 org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery1135424 org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCQlQueryMetaData1132712 org.jboss.proxy.ejb.EJBMetaDataImpl1083456 org.jboss.proxy.ejb.handle.HomeHandleImpl1081728
[JBoss-dev] Re: [JBoss-user] CMR Performance: Weblogic7 Much Faster Then JBoss
Dain, I've moved this to the dev list because I think it's more appropriate. I have now run the benchmark on 4.0. Initial results were disappointing until I realised that debug log output is on in a HEAD build and off in a Branch_3_0 build. Each time, the test was run three times: 1) Create the entities and retrieve; 2) Retrieve again; 3) Flush the cache; 4) Retrieve again. Essentially, the performance is the same, although cache flushing using the jmx-console appears to have done nothing apart from speed up the finder in 4.0. For some reason, finder speed with results in cache is significantly slower. I'm going to add the GlobalTxEntityMap.java fix and try profiling again. The current O(n/2) search of the ArrayList tends to dominate the numbers below. I've appended the container config to the end so that you can review it, as I needed to revise it for 4.0. Here are the results: jboss-4.0.0alpha (as of about an hour ago): 21:52:17,226 INFO [STDOUT] creating 1000 Blobs... 21:52:38,894 INFO [STDOUT] Creation complete, took 21665ms. 21:52:44,278 INFO [STDOUT] testing retrival speed... 21:52:44,280 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 21:52:44,670 INFO [STDOUT] finder took 388ms. 21:52:50,470 INFO [STDOUT] External ValueObject creation took 5798ms for 1000 objects. 21:52:52,052 INFO [STDOUT] Internal ValueObject creation took 1579ms for 1000 objects. 21:52:52,054 INFO [STDOUT] Secondary Retrival, beans are in cache. 21:52:52,565 INFO [STDOUT] finder took 504ms. 21:52:58,086 INFO [STDOUT] External ValueObject creation took 5519ms for 1000 objects. 21:52:59,613 INFO [STDOUT] Internal ValueObject creation took 1524ms for 1000 objects. 21:53:19,111 INFO [STDOUT] testing retrival speed... 21:53:19,113 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 21:53:19,369 INFO [STDOUT] finder took 254ms. 21:53:25,001 INFO [STDOUT] External ValueObject creation took 5629ms for 1000 objects. 21:53:26,536 INFO [STDOUT] Internal ValueObject creation took 1531ms for 1000 objects. 21:53:26,538 INFO [STDOUT] Secondary Retrival, beans are in cache. 21:53:27,014 INFO [STDOUT] finder took 475ms. 21:53:32,583 INFO [STDOUT] External ValueObject creation took 5567ms for 1000 objects. 21:53:34,122 INFO [STDOUT] Internal ValueObject creation took 1537ms for 1000 objects. 21:54:15,752 INFO [EntityContainer] flushing cache 21:54:47,076 INFO [EntityContainer] flushing cache 21:54:56,454 INFO [STDOUT] testing retrival speed... 21:54:56,456 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 21:54:56,693 INFO [STDOUT] finder took 235ms. 21:55:02,582 INFO [STDOUT] External ValueObject creation took 5886ms for 1000 objects. 21:55:04,170 INFO [STDOUT] Internal ValueObject creation took 1585ms for 1000 objects. 21:55:04,172 INFO [STDOUT] Secondary Retrival, beans are in cache. 21:55:04,658 INFO [STDOUT] finder took 475ms. 21:55:10,265 INFO [STDOUT] External ValueObject creation took 5604ms for 1000 objects. 21:55:11,839 INFO [STDOUT] Internal ValueObject creation took 1572ms for 1000 objects. jboss-3.0.5RC1 (before the fix to GlobalTxEntityMap.java): 22:21:18,622 INFO [STDOUT] creating 1000 Blobs... 22:21:39,016 INFO [STDOUT] Creation complete, took 20391ms. 22:21:44,309 INFO [STDOUT] testing retrival speed... 22:21:44,311 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 22:21:44,581 INFO [STDOUT] finder took 268ms. 22:21:50,336 INFO [STDOUT] External ValueObject creation took 5753ms for 1000 objects. 22:21:51,858 INFO [STDOUT] Internal ValueObject creation took 1519ms for 1000 objects. 22:21:51,861 INFO [STDOUT] Secondary Retrival, beans are in cache. 22:21:52,457 INFO [STDOUT] finder took 589ms. 22:21:57,761 INFO [STDOUT] External ValueObject creation took 5301ms for 1000 objects. 22:21:59,272 INFO [STDOUT] Internal ValueObject creation took 1508ms for 1000 objects. 22:22:29,303 INFO [STDOUT] testing retrival speed... 22:22:29,305 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache. 22:22:29,808 INFO [STDOUT] finder took 501ms. 22:22:36,482 INFO [STDOUT] External ValueObject creation took 6672ms for 1000 objects. 22:22:37,988 INFO [STDOUT] Internal ValueObject creation took 1504ms for 1000 objects. 22:22:37,990 INFO [STDOUT] Secondary Retrival, beans are in cache. 22:22:38,597 INFO [STDOUT] finder took 605ms. 22:22:43,968 INFO [STDOUT] External ValueObject creation took 5368ms for 1000 objects. 22:22:45,490 INFO [STDOUT] Internal ValueObject creation took 1520ms for 1000 objects. 22:24:56,018 INFO [EntityContainer] flushing cache 22:25:32,450 INFO [EntityContainer] flushing cache 22:25:49,847 INFO [STDOUT] testing retrival speed... 22:25:49,849 INFO [STDOUT] Initial Retrival, beans may or maynot be in cache.
Re: [JBoss-dev] Shutdown hooks broken on OS X
In my experience, shutdown hooks don't work reliably on *any* version of unix. I was building a command line driven server style of app in java about a year ago and discovered this. Tried it on MacOS X (first), and then thinking it was just the Mac, tried it on solaris (the deployment platform), and it did not work there either. So then I tried linux and HP-UX - no luck there either. I suspect it's an artifact of the limitations on what you can do with unix signal handlers. There is generally only a limited subset of system calls that they can make. Steve C. On Tuesday, November 19, 2002, at 08:01 PM, Dain wrote: The shutdown hooks don't seem to work on OS X (10.2.2). When I press ctrl-c or apple+. the VM just stops cold. Has anyone seen this? I am using the following version of java: bash-2.05a$ java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root_1.3.1_020714-12:46) Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode) -dain --- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.test.cmp2.lob.LOBUnitTestCase Failures
This is one of my tests, which was working a few of weeks ago when I checked it in. I'll look into it tonight (ie. in about ten hours time) and try and figure out what has happened to it. Have any of the other cmp2 tests been changed recently? Steve Coy On Friday, November 15, 2002, at 09:50 AM, Scott M Stark wrote: What are all of these org.jboss.test.cmp2.lob.LOBUnitTestCase failures I see in the 3.2 branch? Everyone is an NPE like the following: null; nested exception is: java.lang.NullPointerException javax.transaction.TransactionRolledbackException: null; nested exception is: java.lang.NullPointerException java.lang.NullPointerException at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createBeanClassInstance (JDBCStoreManager.java:513) at org.jboss.ejb.plugins.CMPPersistenceManager.createBeanClassInstance(CMP PersistenceManager.java:165) at org.jboss.ejb.EntityContainer.createBeanClassInstance(EntityContainer.j ava:272) at org.jboss.ejb.plugins.AbstractInstancePool.get(AbstractInstancePool.jav a:197) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstan ceInterceptor.java:78) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterc eptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreati onInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterc eptor.java:112) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIntercepto rCMT.java:237) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java :71) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityIntercepto r.java:105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:131 ) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFac toryFinderInterceptor.java:125) at org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:475) at org.jboss.ejb.Container.invoke(Container.java:701) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1026) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:100) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java: 88) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.ja va:77) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:80) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:175) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:82) at $Proxy106.create(Unknown Source) at org.jboss.test.cmp2.lob.LOBUnitTestCase.testCreate0(LOBUnitTestCase.jav a:92) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:166) at junit.framework.TestCase.runBare(TestCase.java:140) at net.sourceforge.junitejb.EJBTestCase.runBare(EJBTestCase.java:133) at net.sourceforge.junitejb.EJBTestRunnerBean.runTestCase(EJBTestRunnerBea n.java:102) at net.sourceforge.junitejb.EJBTestRunnerBean.run(EJBTestRunnerBean.java:4 4) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(Sta telessSessionContainer.java:606) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke (CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterc eptor.java:108) at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInt erceptorBMT.java:144) at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Statel essSessionInstanceInterceptor.java:77) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.ja va:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:206) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactory FinderInterceptor.java:154) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContaine r.java:303) at org.jboss.ejb.Container.invoke(Container.java:680) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:34 0) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460 ) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.j ava:701) at java.lang.Thread.run(Thread.java:479) Scott Stark Chief Technology Officer JBoss Group, LLC
[JBoss-dev] MySQL JDBC drivers used on JBoss forums
Hi Jason! I noticed when I was running the CMP2 test suite against mysql that the JDBC drivers prior to the latest had a time zone bug. The effect was that a timestamp that was read back from the database would be an hour or so different from what was stored. This problem goes away with the latest driver from http://www.mysql.com/Downloads/Connector-J/mysql-connector-java- 2.0.14.zip I've noticed that the forum timestamps always seem to be an hour out (at least for me), which looks a lot like a manifestation of this bug. So it might be worthwhile checking into this when you get a chance. Steve Coy --- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Correct release tag?
Did you do a clean build? I've got: 12:07:09,229 INFO [Server] JBoss (MX MicroKernel) [3.0.4 Date:200211041046] Started in 0m:51s:0ms Note the date in your build. Steve Coy On Tuesday, November 5, 2002, at 11:45 AM, Robert Nicholson wrote: My Release id under output is now jboss-3.0.4 but when it starts up I notice that this is the the identifier 07:43:15,519 INFO [Server] JBoss (MX MicroKernel) [3.0.4RC1 Date:200211010050] Started in 0m:21s:157ms --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Cannot build off the head.
You need to check the result of your checkout because you still don't
seem to have everything.
Also confirm that you checked out the right module:
cvs -z9 -q checkout -P jboss-head
This worked for me on the same platform as you.
Steve Coy
On Wednesday, October 23, 2002, at 04:39 PM, Robert Nicholson wrote:
Should the thirdparty directory have xdoclet in it?
I'm trying to build jboss-head on Mac OS 10.2.1 and I'm not getting
anywhere.
the following in libraries.ent suggests that I should have
xdoclet-xdoclet in
thirdparty but in my fresh check out it's not there
!-- XDoclet --
property name=xdoclet.xdoclet.root
value=${project.thirdparty}/xdoclet-xdo
clet/
property name=xdoclet.xdoclet.lib
value=${xdoclet.xdoclet.root}/lib/
path id=xdoclet.xdoclet.classpath
pathelement path=${xdoclet.xdoclet.lib}/commons-logging.jar/
pathelement path=${xdoclet.xdoclet.lib}/xdoclet-bea-module.jar/
pathelement path=${xdoclet.xdoclet.lib}/xdoclet-ejb-module.jar/
pathelement path=${xdoclet.xdoclet.lib}/xdoclet.jar/
pathelement
path=${xdoclet.xdoclet.lib}/xdoclet-java-module.jar/
pathelement
path=${xdoclet.xdoclet.lib}/xdoclet-jboss-module.jar/
pathelement path=${xdoclet.xdoclet.lib}/xdoclet-jdo-module.jar/
pathelement path=${xdoclet.xdoclet.lib}/xdoclet-jmx-module.jar/
pathelement path=${xdoclet.xdoclet.lib}/xdoclet-web-module.jar/
pathelement
path=${xdoclet.xdoclet.lib}/xdoclet-xdoclet-module.jar/
pathelement path=${xdoclet.xdoclet.lib}/xjavadoc.jar/
/path
[Robert-Nicholsons-Computer:~/Archives/jboss-head/thirdparty] robert%
ls -alg
total 0
drwxr-xr-x 19 robert staff 646 Oct 23 12:40 .
drwxr-xr-x 30 robert staff 1020 Oct 23 13:26 ..
drwxr-xr-x 5 robert staff 170 Oct 23 13:23 CVS
drwxr-xr-x 5 robert staff 170 Oct 23 13:29 apache-axis
drwxr-xr-x 6 robert staff 204 Oct 23 12:14 apache-bcel
drwxr-xr-x 4 robert staff 136 Oct 23 12:13 apache-log4j
drwxr-xr-x 5 robert staff 170 Oct 23 12:16 apache-xalan
drwxr-xr-x 4 robert staff 136 Oct 23 12:29 exolab-castor
drwxr-xr-x 4 robert staff 136 Oct 23 12:33 exolab-tyrex
drwxr-xr-x 5 robert staff 170 Oct 23 12:34 gnu-getopt
drwxr-xr-x 4 robert staff 136 Oct 23 12:34 gnu-regexp
drwxr-xr-x 4 robert staff 136 Oct 23 12:34 hsqldb-hsqldb
drwxr-xr-x 4 robert staff 136 Oct 23 12:35 javagroups-javagroups
drwxr-xr-x 4 robert staff 136 Oct 23 12:09 jboss-plastic
drwxr-xr-x 4 robert staff 136 Oct 23 12:37 junit-junit
drwxr-xr-x 4 robert staff 136 Oct 23 12:38 sun-jaas
drwxr-xr-x 4 robert staff 136 Oct 23 12:38 sun-jaf
drwxr-xr-x 5 robert staff 170 Oct 23 12:38 sun-javacc
drwxr-xr-x 4 robert staff 136 Oct 23 12:40 sun-javamail
When I build under OS 10.2.1 I get
[Robert-Nicholsons-Computer:~/Archives/jboss-head/build] robert%
./build.sh
build.sh: Executing: /Users/robert/Archives/jboss-head/tools/bin/ant
-logger org.apache.tools.ant.NoBannerLogger
Buildfile: build.xml
_buildmagic:init:
Trying to override old definition of task property
_buildmagic:init:local-properties:
[copy] Copying 1 file to /Users/robert/Archives/jboss-head/build
BUILD FAILED
file:/Users/robert/Archives/jboss-head/build/../tools/etc/
buildfragments/tools.ent:29: taskdef class
xdoclet.modules.jmx.JMXDocletTask cannot be found
Total time: 4 seconds
---
This sf.net emial is sponsored by: Influence the futureof Java(TM)
technology. Join the Java CommunityProcess(SM) (JCP(SM)) program
now.http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This sf.net emial is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Why do we serialize JAVA_OBJECT, STRUCT and OTHER?
Hi, Currently, if the jdbctype of a database column is one of the above types, the data is explicitly serialized by JBoss 3.x. I've been researching this over the last few days and it seems to me that the materialisation/dematerialisation of these types is really in the domain of the JDBC drivers, and should be accessed using the various set/getObject calls only. If the application programmer wants/needs to have their data explicitly serialised, then they should elect to use one of the binary jdbc types. The presence of the STRUCT type seems pointless at the moment, because java.sql.Struct is not serialisable and there is no method of mapping its content to an EJB attribute, although we could probably do some clever stuff with it later. The use of STRUCT and JAVA_OBJECT is often coupled with the use of a DBMS's abstract datatype system. Oracle, for example, needs to be able to map JAVA_OBJECT to a type previously defined in the schema. It does not permit, for example, a JAVA_OBJECT to be stored in a BLOB column or a RAW(n) column. I want to remove STRUCT altogether, and remove JAVA_OBJECT and OTHER from the binary data types umbrella. At the moment, it's hidden the fact that hsqldb mappings are missing for java.math.BigDecimal, java.sql.Time and java.sql.Date - they just get serialised out as binary data. - Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why do we serialize JAVA_OBJECT, STRUCT and OTHER?
I suspected that something like that was a possibility. If that is the case, then you may as well use one of the binary types, because using JAVA_OBJECT doesn't get you anything at all. On Wednesday, October 2, 2002, at 07:21 PM, Michael Bartmann wrote: Stephen Coy wrote: Hi, Currently, if the jdbctype of a database column is one of the above types, the data is explicitly serialized by JBoss 3.x. I've been researching this over the last few days and it seems to me that the materialisation/dematerialisation of these types is really in the domain of the JDBC drivers, and should be accessed using the various set/getObject calls only. I had problems with that approach when the following conditions all were true - I used ear-scoped classloading. - the JDBC driver was loaded outside (even before creation of) the ear-scope (Which is the case for CMP). - the classes of the objects to be deserialized were not available outside the ear-scope. - the JDBC-driver even if invoked in a thread from the ear-scope did not honour the TCL. This obviously failed. We must consider this when delegating work to the JDBC driver Just my 2Cent, Michael Bartmann If the application programmer wants/needs to have their data explicitly serialised, then they should elect to use one of the binary jdbc types. The presence of the STRUCT type seems pointless at the moment, because java.sql.Struct is not serialisable and there is no method of mapping its content to an EJB attribute, although we could probably do some clever stuff with it later. The use of STRUCT and JAVA_OBJECT is often coupled with the use of a DBMS's abstract datatype system. Oracle, for example, needs to be able to map JAVA_OBJECT to a type previously defined in the schema. It does not permit, for example, a JAVA_OBJECT to be stored in a BLOB column or a RAW(n) column. I want to remove STRUCT altogether, and remove JAVA_OBJECT and OTHER from the binary data types umbrella. At the moment, it's hidden the fact that hsqldb mappings are missing for java.math.BigDecimal, java.sql.Time and java.sql.Date - they just get serialised out as binary data. - Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Problem in LocalManagedConnectionFactory.getConnectionProperties(Subject ...
Hi David, I'm currently working in Branch_3_2, trying to get our app running under it, amongst other things. We set up a number of different datasources, all pointing at various Oracle databases, using the -service.xml style of configuration, and also using security domains set up in login-config.xml. On deployment, JBoss is throwing a ResourceException No matching credentials in Subject!, because this line in LocalManagedConnectionFactory.java does not work properly: if (o instanceof PasswordCredential ((PasswordCredential)o).getManagedConnectionFactory() == this) It's around about line 409 (I've been adding log.debug statements) in Properties getConnectionProperties(Subject subject, ConnectionRequestInfo cri). It seems that getManagedConnectionFactory is returning a proxy, so the comparison with 'this' fails. Changing it to: if (o instanceof PasswordCredential ((PasswordCredential)o).getManagedConnectionFactory().equals(this)) seems to work, but I'm not certain of the validity of this change. I'm using the standard Apple 1.3.1 JRE/JDK. Regards, Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem in LocalManagedConnectionFactory.getConnectionProperties(Subject ...
Yes. It appears to work, because the proxy seems to reference the same object. At least, it returns the same hashCode, and equals works. Now I have to figure out why javax.ejb.EntityContext.getEJBObject has started throwing java.lang.IllegalStateException: No remote interface defined., but that's another story. On Tuesday, October 1, 2002, at 07:26 AM, David Jencks wrote: Thanks for pointing out this problem. I applied your change and a couple others that provide a more permanent solution to Branch_3_2 and HEAD. Does your fix really work? I'd expect the proxy and actual instance not to be equal since they have different classes... Thanks again... I should have written a test... david jencks On 2002.09.30 04:57:05 -0400 Stephen Coy wrote: Hi David, I'm currently working in Branch_3_2, trying to get our app running under it, amongst other things. We set up a number of different datasources, all pointing at various Oracle databases, using the -service.xml style of configuration, and also using security domains set up in login-config.xml. On deployment, JBoss is throwing a ResourceException No matching credentials in Subject!, because this line in LocalManagedConnectionFactory.java does not work properly: if (o instanceof PasswordCredential ((PasswordCredential)o).getManagedConnectionFactory() == this) It's around about line 409 (I've been adding log.debug statements) in Properties getConnectionProperties(Subject subject, ConnectionRequestInfo cri). It seems that getManagedConnectionFactory is returning a proxy, so the comparison with 'this' fails. Changing it to: if (o instanceof PasswordCredential ((PasswordCredential)o).getManagedConnectionFactory().equals(this)) seems to work, but I'm not certain of the validity of this change. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Cleaning up LOB support in JDBCUtil.java
Hi Dain, I've been doing some work on making the binary data support more portable in JDBCUtil.java. In particular, I wanted to get all use cases of this working with Oracle, where (despite what I may have said before) there are still issues with BLOBS. Current Oracle JDBC drivers absolutely do support the use of the java.sql.* apis for accessing LOBS and the other forms of binary data (VARBINARY, etc). I believe that you added the code that uses org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob to try and resolve the Oracle issues. Please correct me if I am wrong as I've ditched it because Oracle barfs on it (technically, the provision of a java.sql.Blob implementation is in the driver's domain). The only other issue was the use of byte[] bytes = rs.getBytes(index); in getResult. According to the javadoc, ResultSet.getBytes() returns raw bytes from the driver. In Oracle's case, this seems to be the LOB pointer or something, rather than the LOB data. However, going direct to ResultSet.getBinaryStream works fine, so I've modified convertByteArrayToObject to take an InputStream instead, which seems to be a bit more streamlined as you were wrapping the array in a ByteArrayInputStream anyway, unless it already happened to be expecting a byte array. Currently, I have my changes working in Branch_3_0, and the cmp2 test suite passes using both Hypersonic and Oracle. I'll get it working in Branch_3_2 as well. I want to emphasize that I have not used any Oracle apis for this work, only the java.sql.* interfaces. This will not fix the Oracle issues with LOB size when using the thin drivers. The only way to fix that problem is to use the oci drivers. Anyway, I wanted to run this past you and make sure that I'm not working at cross purposes with anyone else before checking it in. Steve Coy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deadlock retry interceptor
I think so too, because it's a real pain to do retrying from client code We spent a great deal of time eliminating deadlocks in our application. For what it's worth, my fix for bug #601097 eliminated many of them. On Thursday, September 12, 2002, at 08:02 AM, Bill Burke wrote: Great fucking idea! I shoulda thought of that. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Michael Bartmann Sent: Wednesday, September 11, 2002 4:07 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Deadlock retry interceptor Hi deadlock lovers, I just did a deadlock-retry-interceptor, which was more easy than I thought. There is a serverside variant and a client interceptor. I don't think you need a client interceptor. Only serverside. The reason? You need to do the retry outside the transaction. The transaction must be able to rollback before you can retry it. The interesting (i.e. non-perfect) points are: - how to configure retry strategy (quite simple now) - where to place the serverside thing in the chain (should be _outside_ of the transaction which just rolled back due to the deadlock; this probably implies that it could have to be done inside the TxInterceptor when entering a new tx. When _not_ doing RequiresNew the interceptor works fine between the SecutiyInterceptor and the TxInterceptor (I tried this with SLSB). You can only do a retry if the Beans starts a transaction. Required(if tx started) or RequiresNew. I think this stuff should be in the TxInterceptor, and maybe only the Container Managed one. - what to do with MDB (they are supposed to catch everything, so nothing gets through to the interceptor. My best guess is to use a UserTX inside the MDB, do the retry manually (w/o interceptor) and put all this in an AbstractDeadlockRetryMDB (I did this, it worked fine). Can't you put it in the TxInterceptor for MDB? Is there any interest to put this into Branch_3_2? Send it to me. I'll get it in. Its definately worth it. Bill --- In remembrance www.osdn.com/911/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Interrupted while requesting permit!
Hi Did this get fixed in Branch_3_0? If it did, then it is still happening, because I've just encountered it in a fresh build today. If it's not in this branch yet, I think it's kind of important that it goes in for 3.0.2, as it makes JBoss unreliable. Full exception trace below. Stephen Coy 2002-08-27 15:33:27,320 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.Priv.findForUser] Find failed org.jboss.util.NestedSQLException: Interrupted while requesting permit!; - nested throwable: (javax.resource.ResourceException: Interrupted while requesting permit!) at org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection (LocalDataSource.java:106) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute (JDBCAbstractQueryCommand.java:92) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute (JDBCFindEntityCommand.java:44) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity (JDBCStoreManager.java:541) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity (CMPPersistenceManager.java:336) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity( CachedConnectionInterceptor.java:301) at org.jboss.ejb.EntityContainer.find(EntityContainer.java:687) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome (EntityContainer.java:1116) at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java: 73) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome (EntitySynchronizationInterceptor.java:209) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome( CachedConnectionInterceptor.java:215) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome (EntityInstanceInterceptor.java:88) at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome (EntityLockInterceptor.java:79) at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome (EntityCreationInterceptor.java:44) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext (AbstractTxInterceptor.java:111) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions (TxInterceptorCMT.java:178) at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:52) at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java: 105) at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:129) at org.jboss.ejb.EntityContainer.invokeHome(EntityContainer.java:487) at org.jboss.ejb.Container.invoke(Container.java:738) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java: 73) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:198) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:76) at $Proxy396.findForUser(Unknown Source) at com.whitesmiths.sacha.web.common.PrivChecker.checkPrivStatus(PrivChecker.java: 370) at com.whitesmiths.sacha.web.common.Utilities.checkAccessSettings(Utilities.java: 238) at com.whitesmiths.sacha.web.tagsupport.CheckPrivTag.doStartTag (CheckPrivTag.java:83) at org.apache.jsp.listWorklists$jsp._jspService(listWorklists$jsp.java:89) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service (JspServlet.java:201) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:381) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:473) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:344) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch (WebApplicationHandler.java:313) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:554) at org.mortbay.jetty.servlet.WebApplicationHandler.handle (WebApplicationHandler.java:199) at org.mortbay.http.HttpContext.handle(HttpContext.java:1572) at org.mortbay.http.HttpContext.handle(HttpContext.java:1522) at org.mortbay.http.HttpServer.service(HttpServer.java:795) at org.jboss.jetty.Jetty.service(Jetty.java:531) at org.mortbay.http.HttpConnection.service(HttpConnection.java:784
Re: [JBoss-dev] [ jboss-Bugs-551533 ] EJB-QL - missing in generated SQL
Doh! which fails completely because there is *no* t6_rs_role in the FROM clause. The relationships are: Privs *^ | Roles ^ *| UserRoleSeq *^ | Users (best viewed in a fixed width font!) On Monday, July 1, 2002, at 08:19 PM, [EMAIL PROTECTED] wrote: which fails completely because there is t6_rs_role in the FROM clause. The relationships are: Privs *^ | Roles ^ *| UserRoleSeq *^ | Users --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Oracle BLOB handling - FIXED?
Initial testing in Oracle 9i was not promising (using the latest driver (Oracle JDBC Driver version - 9.0.2.0.0): 2002-06-18 23:39:05,843 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.SimpleEJB] Executing SQL: UPDATE SIMPLE SET booleanPrimitive=?, booleanObject=?, bytePrimitive=?, byteObject=?, shortPrimitive=?, shortObject=?, integerPrimitive=?, integerObject=?, longPrimitive=?, longObject=?, floatPrimitive=?, floatObject=?, doublePrimitive=?, doubleObject=?, stringValue=?, utilDateValue=?, sqlDateValue=?, timeValue=?, timestampValue=?, bigDecimalValue=?, byteArrayValue=?, objectValue=? WHERE id=? 2002-06-18 23:39:05,848 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanPrimitive] Set parameter: index=1, jdbcType=BIT, value=true 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanObject] Set parameter: index=2, jdbcType=BIT, value=false 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePrimitive] Set parameter: index=3, jdbcType=TINYINT, value=11 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteObject] Set parameter: index=4, jdbcType=TINYINT, value=22 2002-06-18 23:39:05,849 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortPrimitive] Set parameter: index=5, jdbcType=SMALLINT, value=33 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortObject] Set parameter: index=6, jdbcType=SMALLINT, value=44 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerPrimitive] Set parameter: index=7, jdbcType=INTEGER, value=55 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerObject] Set parameter: index=8, jdbcType=INTEGER, value=66 2002-06-18 23:39:05,850 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPrimitive] Set parameter: index=9, jdbcType=BIGINT, value=77 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longObject] Set parameter: index=10, jdbcType=BIGINT, value=88 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatPrimitive] Set parameter: index=11, jdbcType=REAL, value=11.11 2002-06-18 23:39:05,851 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatObject] Set parameter: index=12, jdbcType=REAL, value=22.22 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doublePrimitive] Set parameter: index=13, jdbcType=DOUBLE, value=33.33 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doubleObject] Set parameter: index=14, jdbcType=DOUBLE, value=44.44 2002-06-18 23:39:05,855 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.stringValue] Set parameter: index=15, jdbcType=VARCHAR, value=test string value 2002-06-18 23:39:05,856 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.utilDateValue] Set parameter: index=16, jdbcType=TIMESTAMP, value=Thu Jan 01 11:00:01 EST 1970 2002-06-18 23:39:05,856 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.sqlDateValue] Set parameter: index=17, jdbcType=DATE, value=1981-05-05 2002-06-18 23:39:05,857 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timeValue] Set parameter: index=18, jdbcType=TIME, value=22:33:44 2002-06-18 23:39:05,858 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timestampValue] Set parameter: index=19, jdbcType=TIMESTAMP, value=1970-01-01 11:00:04.444 2002-06-18 23:39:05,858 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bigDecimalValue] Set parameter: index=20, jdbcType=DECIMAL, value=12345678 2002-06-18 23:39:05,859 TRACE [org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteArrayValue] Set parameter: index=21, jdbcType=BLOB, value=[B@2d54c5 2002-06-18 23:39:05,861 ERROR [org.jboss.ejb.GlobalTxEntityMap] Store failed on entity: simple javax.ejb.EJBException: Store failed; CausedByException is: org.jboss.ejb.plugins.cmp.jdbc.ByteArrayBlob at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute (JDBCStoreEntityCommand.java:94) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity (JDBCStoreManager.java:586) at org.jboss.ejb.plugins.CMPPersistenceManager.storeEntity (CMPPersistenceManager.java:458) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.storeEntity( CachedConnectionInterceptor.java:388) at
Re: [JBoss-dev] Oracle BLOB handling - FIXED?
I've done some more poking at this, and modified JDBCUtil.setParameter
as follows:
//
// Binary types need to be converted to a byte array and set
//
if(isBinaryJDBCType(jdbcType))
{
byte[] bytes = convertObjectToByteArray(value);
if (bytes.length 2000 jdbcType != Types.BLOB)
{
// it's more efficient to use setBinaryStream for large
// streams, and causes problems if not done on some DBMS
// implementations
ps.setBytes(index, bytes);
} else
{
InputStream in = null;
try
{
in = new ByteArrayInputStream(bytes);
ps.setBinaryStream(index, in, bytes.length);
} finally
{
safeClose(in);
}
}
return;
ie. Forget about the ByteArrayBlob class.
This works fine when writing to the database.
However, reading the data back fails:
2002-06-18 23:59:20,671 DEBUG
[org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.SimpleEJB]
Executing SQL: SELECT booleanPrimitive, booleanObject, bytePrimitive,
byteObject, shortPrimitive, shortObject, integerPrimitive,
integerObject, longPrimitive, longObject, floatPrimitive, floatObject,
doublePrimitive, doubleObject, stringValue, utilDateValue, sqlDateValue,
timeValue, timestampValue, bigDecimalValue, byteArrayValue, objectValue
FROM SIMPLE WHERE (id=?)
2002-06-18 23:59:20,680 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.id]
Set parameter: index=1, jdbcType=VARCHAR, value=simple
2002-06-18 23:59:20,707 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanPrimitive]
Get result: index=1, javaType=boolean, Simple, value=true
2002-06-18 23:59:20,709 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.booleanObject]
Get result: index=2, javaType=java.lang.Boolean, Simple, value=false
2002-06-18 23:59:20,713 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.bytePrimitive]
Get result: index=3, javaType=byte, Simple, value=11
2002-06-18 23:59:20,715 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.byteObject]
Get result: index=4, javaType=java.lang.Byte, Simple, value=22
2002-06-18 23:59:20,717 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortPrimitive]
Get result: index=5, javaType=short, Simple, value=33
2002-06-18 23:59:20,718 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.shortObject]
Get result: index=6, javaType=java.lang.Short, Simple, value=44
2002-06-18 23:59:20,720 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerPrimitive]
Get result: index=7, javaType=int, Simple, value=55
2002-06-18 23:59:20,726 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.integerObject]
Get result: index=8, javaType=java.lang.Integer, Simple, value=66
2002-06-18 23:59:20,728 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longPrimitive]
Get result: index=9, javaType=long, Simple, value=77
2002-06-18 23:59:20,730 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.longObject]
Get result: index=10, javaType=java.lang.Long, Simple, value=88
2002-06-18 23:59:20,731 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatPrimitive]
Get result: index=11, javaType=float, Simple, value=11.11
2002-06-18 23:59:20,733 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.floatObject]
Get result: index=12, javaType=java.lang.Float, Simple, value=22.22
2002-06-18 23:59:20,735 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doublePrimitive]
Get result: index=13, javaType=double, Simple, value=33.33
2002-06-18 23:59:20,738 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.doubleObject]
Get result: index=14, javaType=java.lang.Double, Simple, value=44.44
2002-06-18 23:59:20,740 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.stringValue]
Get result: index=15, javaType=java.lang.String, Simple, value=test
string value
2002-06-18 23:59:20,742 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.utilDateValue]
Get result: index=16, javaType=java.util.Date, Simple, value=1970-01-01
11:00:01.111
2002-06-18 23:59:20,744 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.sqlDateValue]
Get result: index=17, javaType=java.sql.Date, Simple, value=1981-05-05
2002-06-18 23:59:20,746 TRACE
[org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMP2xFieldBridge.SimpleEJB.timeValue]
Get result: index=18, javaType=java.sql.Time, Simple, value=22:33:44
2002-06-18 23:59:20,748 TRACE
Re: [JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 2-June-2002
Scott,
Have you noticed that this URL is broken?
On Monday, June 3, 2002, at 05:37 AM, [EMAIL PROTECTED] wrote:
See http://lubega.com/testarchive/${build.uid} for details of this test.
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Possible to use Jikes to compile Jsp with Jetty?
One of our guys came up with this target in our build file:
!-- Generate java from Jsp files and compile them --
target name=jsp-precompile
depends=prepare,compile,dummy_webdoclet unless=no-jsp-precompile
java classname=org.apache.jasper.JspC fork=true
classpath
pathelement
location=${jboss.dist}/lib/org.apache.jasper.jar /
pathelement
location=${jboss.dist}/lib/javax.servlet.jar /
pathelement location=${jboss.dist}/lib/crimson.jar
/
/classpath
arg value=-d /
arg value=${jsp.precompile.tmpdir} /
arg value=-p /
arg value=JspServ /
arg value=-webinc /
arg value=merge/gen-mappings.xml /
arg value=-webapp /
arg value=${build.dir} /
/java
javac srcdir=${jsp.precompile.tmpdir}
destdir=${build.dir}/WEB-INF/classes
classpathref=jsp.precompile.path
debug=${debug}
optimize=${optimise}
deprecation=on /
/target
Is that enough for you to go on?
On Thursday, May 30, 2002, at 04:14 PM, Jason Dillon wrote:
If so, can some one explain this to me. Jsp compiles are killing us on
the
website, hard to test new versions...
--jason
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Branch_3_0 seems to hang sometimes
I'm running the MacOS X 1.3.1 VM Here's a thread dump, with a bit of log context around it: 11:40:53,918 INFO [Server] JBoss (MX MicroKernel) [3.0.0RC4 Date:200205301431] Started in 1m:26s:143ms 11:41:29,704 INFO [RefNumBean] Next refNum is: 2644 Full thread dump: RMI TCP Connection(8)-192.168.0.102 daemon prio=5 tid=0x46fd370 nid=0x4351620 waiting on monitor [0x4c06000..0x4c07b48] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.jboss.mx.loading.UnifiedLoaderRepository$ReentrantLock.acquire (UnifiedLoaderRepository.java:793) at org.jboss.mx.loading.UnifiedLoaderRepository.synchronize (UnifiedLoaderRepository.java:180) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass (UnifiedLoaderRepository.java:124) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java: 285) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.jboss.invocation.MarshalledValueInputStream.resolveClass (MarshalledValueInputStream.java:41) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:68) at org.jboss.invocation.MarshalledInvocation.getValue(MarshalledInvocation.java: 276) at org.jboss.invocation.Invocation.getObjectName(Invocation.java:221) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:359) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run(Transport.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java: 706) at java.lang.Thread.run(Thread.java:496) RMI TCP Connection(7)-192.168.0.102 daemon prio=5 tid=0x46fbf20 nid=0x43513c0 waiting on monitor [0x4b85000..0x4b86b48] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at org.jboss.mx.loading.UnifiedLoaderRepository$ReentrantLock.acquire (UnifiedLoaderRepository.java:793) at org.jboss.mx.loading.UnifiedLoaderRepository.synchronize (UnifiedLoaderRepository.java:180) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass (UnifiedLoaderRepository.java:124) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java: 285) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at org.jboss.invocation.MarshalledValueInputStream.resolveClass (MarshalledValueInputStream.java:41) at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at org.jboss.invocation.MarshalledValue.get(MarshalledValue.java:68) at org.jboss.invocation.MarshalledInvocation.getValue(MarshalledInvocation.java: 276) at org.jboss.invocation.Invocation.getObjectName(Invocation.java:221) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:359) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241) at sun.rmi.transport.Transport$1.run(Transport.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:148) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:465) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java: 706) at java.lang.Thread.run(Thread.java:496) RMI TCP Connection(6)-192.168.0.102 daemon prio=5 tid=0x46fad60 nid=0x43510e0 waiting on monitor [0x4b02000..0x4b05b48] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:420) at
Re: [JBoss-dev] Build not working on Linux?
Maybe this is the reason that the build has been barfing on MacOS X as
well.
I've been getting the same problem that Scott Stark mentioned yesterday,
but it is not very deterministic.
ie. yesterday's CVS checkout stops in a different place to today's CVS
checkout.
It's not difficult to imagine low memory somehow mapping to a
FileNotFound exception (which is what is causing the
IllegalStateException on MacOS X) somewhere in the JVM implementation.
On Sunday, May 26, 2002, at 02:30 PM, Matthew Tippett wrote:
Technically speaking the docset is not 'too big', it is simply causes
too many native threads to be created for most 'default' Linux
distributions.
Run the sample program and you should with a Linux 2.4 system get around
220ish threads. The options without the change are as follows.
o Use build.compiler=classic (which kicks the JVM into green
threads which doesn't have a 'real' thread limit.
o Set ulimit -u to greater around 1024
o Modify /etc/security/limits.conf and nprocs to something
around 1024
So the 'fix' is a workaround. (Probably is the best solution for the
moment, but it isn't a bug in the code, more so a configuration problem
in the standard configuration of Linux distributions.
Just thought people might be interested (I spent about 2 hours
attempting to get my first CVS build running when I came across this
problem :).
Regards,
Matthew 'The new developer on the block' Tippett
Francisco Reverbel wrote:
Found the cause: a recent change on server/build.xml made xdoclet to
be called on a fileset too big (name=**/*.java). I will revert the
change. But it is strange that nobody else saw this... I have tried
two Linux machines (a laptop with 128M and a box with 384M) with the
same result: xdoclet barfed on the big fileset. Maybe there is
something in my Linux environment that mademe run out of memory
before anybody else.
leset
Running xdoclet.XDocletMain loaded by
sun.misc.Launcher$AppClassLoader. Forked:\
true
[xdoclet] Running mbeanInterface/
[xdoclet] java.lang.OutOfMemoryError: unable to create new native
thread
-- Matthew Tippett - [EMAIL PROTECTED]
Toronto, Canada - (416) 435-4118
public class TestThread extends Thread {
public static void main(String argv[]) {
int i=0;
while(true) {
TestThread thread = new TestThread();
try {
thread.start();
} catch (Throwable e) {
System.out.println(Maximum number of threads is
+Thread.activeCount());
System.exit(-1);
}
}
}
public void run() {
while (true) {
try {
sleep(1);
} catch (Exception e) {
}
}
}
}
___
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Fwd: Bug when converting EJB QL boolean comparisons from true and false to 1 and 0
Begin forwarded message:
Hi All,
I think I have found a bug when specifying your own finder method with EJB QL and Oracle.
The problem is that in EJB QL any comparisons to a boolean field must be made using the keywords TRUE or FALSE. When I do this I get an exception come back fromOracle telling me it doesn't know the field name. It seems that JBoss is not converting the TRUE or FALSE to a 1 or 0 when it sends the SQL to Oracle, that is, "...wheremyBoolean = true" is being sent to Oracle.
I have tried all possible sensible jdbc-type> to sql-type> tags in the XML files.
Anyway,I have created a unit test package for this - it is attached. It plugs into the JBoss testsuite. To compile the test, you will need to add the following to the jboss-all/testsuite/build.xml:
target name="jars" description="Builds all jar files." depends="compile,
...
_jars-dbtest,
_jars-findWhereBoolean,
...
_jars-bankiiop">
/target>
!-- findWhereBoolean test -->
target name="_jars-findWhereBoolean">
mkdir dir="${build.lib}"/>
!-- build findWhereBooleanTestClient.jar -->
jar jarfile="${build.lib}/findWhereBooleanTestClient.jar" manifest="${build.etc}/manifest.mf">
fileset dir="${build.classes}">
patternset refid="common.test.client.classes"/>
include name="org/jboss/test/findWhereBoolean/interfaces/**"/>
include name="org/jboss/test/findWhereBoolean/test/**"/>
/fileset>
fileset dir="${build.resources}/findWhereBoolean">
include name="*.*"/>
/fileset>
/jar>
!-- build findWhereBoolean.jar -->
jar jarfile="${build.lib}/findWhereBoolean.jar">
fileset dir="${build.classes}">
patternset refid="common.test.application.classes"/>
include name="org/jboss/test/findWhereBoolean/interfaces/**"/>
include name="org/jboss/test/findWhereBoolean/bean/**"/>
/fileset>
fileset dir="${build.resources}/findWhereBoolean">
include name="**/*.xml"/>
/fileset>
/jar>
/target>
If you're interested, the actual JBoss server.log error message and stack trace is:
2002-05-13 18:18:45,506 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.CMP2Entity.findAllWhereBooleanIsTrue] Executing SQL: SELECT DISTINCT t0_bean.a_Boolean, t0_bean.an_Int, t0_bean.a_Long, t0_bean.a_Double, t0_bean.a_String FROM CMP2ENTITY t0_bean WHERE t0_bean.a_Boolean = true
2002-05-13 18:18:45,516 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCEJBQLQuery.CMP2Entity.findAllWhereBooleanIsTrue] Find failed
java.sql.SQLException: ORA-00904: invalid column name
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:180)
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:1451)
at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:651)
at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:2117)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2331)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:422)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:366)
at org.jboss.resource.adapter.jdbc.local.PreparedStatementInPool.executeQuery(PreparedStatementInPool.java:862)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstractQueryCommand.java:107)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFindEntitiesCommand.java:40)
at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreManager.java:466)
at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistenceManager.java:348)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntities(CachedConnectionInterceptor.java:284)
at org.jboss.ejb.EntityContainer.find(EntityContainer.java:662)
at java.lang.reflect.Method.invoke(Native Method)
at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:)
at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:73)
at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:230)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:176)
at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:79)
at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:44)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:98)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:167)
at
[JBoss-dev] Wrong credentials passed to getConnection!
I'm running the current Branch_3_0 code and the above message has started appearing in the last few days when deploying my ejb jar file. I have an Oracle DS setup as per the example in jboss- all/connector/src/etc/example-config/oracle-service.xml and the appropriate security realm set up in login-config.xml. What could have changed that would stop this from working? Here's the console output: 13:35:57,139 ERROR [EntityContainer] Exception in service lifecyle operation: create 13:35:57,144 ERROR [STDERR] java.sql.SQLException: ResourceException javax.resource.ResourceException: Wrong credentials passed to getConnection! 13:35:57,146 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection (LocalDataSource.java:105) 13:35:57,148 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.fixTableName(SQLUtil.java:38) 13:35:57,148 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.init (JDBCEntityBridge.java:103) 13:35:57,184 ERROR [STDERR] at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.create(JDBCStoreManager.java: 333) 13:35:57,186 ERROR [STDERR] at org.jboss.ejb.plugins.CMPPersistenceManager.create(CMPPersistenceManager.java: 155) 13:35:57,188 ERROR [STDERR] at org.jboss.ejb.EntityContainer.create(EntityContainer.java:337) 13:35:57,189 ERROR [STDERR] at org.jboss.ejb.Container.invoke(Container.java:790) 13:35:57,190 ERROR [STDERR] at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055) 13:35:57,192 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) 13:35:57,193 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java: 867) 13:35:57,195 ERROR [STDERR] at $Proxy0.create(Unknown Source) 13:35:57,196 ERROR [STDERR] at org.jboss.system.ServiceController.create(ServiceController.java:271) 13:35:57,198 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:35:57,200 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) 13:35:57,202 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) 13:35:57,203 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) 13:35:57,204 ERROR [STDERR] at $Proxy19.create(Unknown Source) 13:35:57,206 ERROR [STDERR] at org.jboss.ejb.EjbModule.createService(EjbModule.java:392) 13:35:57,207 ERROR [STDERR] at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) 13:35:57,209 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:35:57,210 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) 13:35:57,212 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) 13:35:57,213 ERROR [STDERR] at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java: 867) 13:35:57,215 ERROR [STDERR] at $Proxy0.create(Unknown Source) 13:35:57,216 ERROR [STDERR] at org.jboss.system.ServiceController.create(ServiceController.java:271) 13:35:57,218 ERROR [STDERR] at org.jboss.system.ServiceController.create(ServiceController.java:211) 13:35:57,219 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:35:57,221 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) 13:35:57,263 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) 13:35:57,265 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) 13:35:57,267 ERROR [STDERR] at $Proxy5.create(Unknown Source) 13:35:57,268 ERROR [STDERR] at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) 13:35:57,269 ERROR [STDERR] at org.jboss.deployment.MainDeployer.create(MainDeployer.java:651) 13:35:57,271 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:526) 13:35:57,272 ERROR [STDERR] at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490) 13:35:57,274 ERROR [STDERR] at java.lang.reflect.Method.invoke(Native Method) 13:35:57,275 ERROR [STDERR] at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke (ReflectedMBeanDispatcher.java:284) 13:35:57,277 ERROR [STDERR] at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) 13:35:57,278 ERROR [STDERR] at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) 13:35:57,280 ERROR [STDERR] at $Proxy4.deploy(Unknown Source) 13:35:57,282 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.deploy (URLDeploymentScanner.java:405) 13:35:57,283 ERROR [STDERR] at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory (URLDeploymentScanner.java:586) 13:35:57,285 ERROR [STDERR] at
[JBoss-dev] Re: Wrong credentials passed to getConnection!
Futher investigation reveals the following code in jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/local/LocalManagedConnection.
java:
private void checkIdentity(Subject subject, ConnectionRequestInfo cri)
throws ResourceException
{
Properties newProps = mcf.getConnectionProperties(subject, cri);
if (!props.equals(newProps))
{
props.list(System.err);
newProps.list(System.err);
throw new ResourceException(Wrong credentials passed to
getConnection! );
} // end of if ()
}
You can see that I've added some debugging statements which reveal:
13:51:32,730 ERROR [STDERR] -- listing properties --
13:51:32,731 ERROR [STDERR] user=steve
13:51:32,733 ERROR [STDERR] password=
13:51:32,733 ERROR [STDERR] dll=ocijdbc9
13:51:32,735 ERROR [STDERR] protocol=thin
13:51:32,735 ERROR [STDERR] -- listing properties --
13:51:32,735 ERROR [STDERR] user=steve
13:51:32,738 ERROR [STDERR] password=
13:51:32,770 ERROR [EntityContainer] Exception in service lifecyle
operation: create
so I think it's fair to assume that it is unreasonable to compare these
property lists for equality.
On Wednesday, May 1, 2002, at 01:40 PM, Stephen Coy wrote:
I'm running the current Branch_3_0 code and the above message has
started appearing in the last few days when deploying my ejb jar file.
I have an Oracle DS setup as per the example in jboss-
all/connector/src/etc/example-config/oracle-service.xml and the
appropriate security realm set up in login-config.xml. What could have
changed that would stop this from working?
Here's the console output:
13:35:57,139 ERROR [EntityContainer] Exception in service lifecyle
operation: create
13:35:57,144 ERROR [STDERR] java.sql.SQLException: ResourceException
javax.resource.ResourceException: Wrong credentials passed to
getConnection!
13:35:57,146 ERROR [STDERR] at
org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection
(LocalDataSource.java:105)
13:35:57,148 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.fixTableName(SQLUtil.java:38)
13:35:57,148 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.init
(JDBCEntityBridge.java:103)
13:35:57,184 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.create(JDBCStoreManager.java:
333)
13:35:57,186 ERROR [STDERR] at
org.jboss.ejb.plugins.CMPPersistenceManager.create
(CMPPersistenceManager.java:
155)
13:35:57,188 ERROR [STDERR] at
org.jboss.ejb.EntityContainer.create(EntityContainer.java:337)
13:35:57,189 ERROR [STDERR] at
org.jboss.ejb.Container.invoke(Container.java:790)
13:35:57,190 ERROR [STDERR] at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055)
13:35:57,192 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,193 ERROR [STDERR] at
org.jboss.system.ServiceController$ServiceProxy.invoke
(ServiceController.java:
867)
13:35:57,195 ERROR [STDERR] at $Proxy0.create(Unknown Source)
13:35:57,196 ERROR [STDERR] at
org.jboss.system.ServiceController.create(ServiceController.java:271)
13:35:57,198 ERROR [STDERR] at
java.lang.reflect.Method.invoke(Native Method)
13:35:57,200 ERROR [STDERR] at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke
(ReflectedMBeanDispatcher.java:284)
13:35:57,202 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,203 ERROR [STDERR] at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
13:35:57,204 ERROR [STDERR] at $Proxy19.create(Unknown Source)
13:35:57,206 ERROR [STDERR] at
org.jboss.ejb.EjbModule.createService(EjbModule.java:392)
13:35:57,207 ERROR [STDERR] at
org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134)
13:35:57,209 ERROR [STDERR] at
java.lang.reflect.Method.invoke(Native Method)
13:35:57,210 ERROR [STDERR] at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke
(ReflectedMBeanDispatcher.java:284)
13:35:57,212 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,213 ERROR [STDERR] at
org.jboss.system.ServiceController$ServiceProxy.invoke
(ServiceController.java:
867)
13:35:57,215 ERROR [STDERR] at $Proxy0.create(Unknown Source)
13:35:57,216 ERROR [STDERR] at
org.jboss.system.ServiceController.create(ServiceController.java:271)
13:35:57,218 ERROR [STDERR] at
org.jboss.system.ServiceController.create(ServiceController.java:211)
13:35:57,219 ERROR [STDERR] at
java.lang.reflect.Method.invoke(Native Method)
13:35:57,221 ERROR [STDERR] at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke
(ReflectedMBeanDispatcher.java:284)
13:35:57,263 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,265 ERROR [STDERR
Re: [JBoss-dev] Re: Wrong credentials passed to getConnection!
I was beginning to think that I was talking to myself here :-)
It looks like
org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.matchManagedConnections
has the same problem.
I will make this change and let you know. At the moment, I changed the
above function plus LocalManagedConnection to compare the user and
password properties for equality instead.
On Wednesday, May 1, 2002, at 02:44 PM, David Jencks wrote:
I was assuming that a driver would not change the properties passed to
it
on a getConnection(properties) call, but I was WRONG!! Oracle in their
infinite wisdom is adding some more properties.
Can you check if changing line 115 of LocalManagedConnectionFactory to
Connection con =
getDriver().connect(internalGetConnectionURL(),
new Properties(props));
fixes the problem?
Thanks
david jencks
On 2002.04.30 23:59:29 -0400 Stephen Coy wrote:
Futher investigation reveals the following code in jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/local/LocalManagedConnection.
java:
private void checkIdentity(Subject subject, ConnectionRequestInfo
cri)
throws ResourceException
{
Properties newProps = mcf.getConnectionProperties(subject, cri);
if (!props.equals(newProps))
{
props.list(System.err);
newProps.list(System.err);
throw new ResourceException(Wrong credentials passed to
getConnection! );
} // end of if ()
}
You can see that I've added some debugging statements which reveal:
13:51:32,730 ERROR [STDERR] -- listing properties --
13:51:32,731 ERROR [STDERR] user=steve
13:51:32,733 ERROR [STDERR] password=
13:51:32,733 ERROR [STDERR] dll=ocijdbc9
13:51:32,735 ERROR [STDERR] protocol=thin
13:51:32,735 ERROR [STDERR] -- listing properties --
13:51:32,735 ERROR [STDERR] user=steve
13:51:32,738 ERROR [STDERR] password=
13:51:32,770 ERROR [EntityContainer] Exception in service lifecyle
operation: create
so I think it's fair to assume that it is unreasonable to compare these
property lists for equality.
On Wednesday, May 1, 2002, at 01:40 PM, Stephen Coy wrote:
I'm running the current Branch_3_0 code and the above message has
started appearing in the last few days when deploying my ejb jar file.
I have an Oracle DS setup as per the example in jboss-
all/connector/src/etc/example-config/oracle-service.xml and the
appropriate security realm set up in login-config.xml. What could have
changed that would stop this from working?
Here's the console output:
13:35:57,139 ERROR [EntityContainer] Exception in service lifecyle
operation: create
13:35:57,144 ERROR [STDERR] java.sql.SQLException: ResourceException
javax.resource.ResourceException: Wrong credentials passed to
getConnection!
13:35:57,146 ERROR [STDERR] at
org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection
(LocalDataSource.java:105)
13:35:57,148 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.fixTableName(SQLUtil.java:38)
13:35:57,148 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.init
(JDBCEntityBridge.java:103)
13:35:57,184 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.create
(JDBCStoreManager.java:
333)
13:35:57,186 ERROR [STDERR] at
org.jboss.ejb.plugins.CMPPersistenceManager.create
(CMPPersistenceManager.java:
155)
13:35:57,188 ERROR [STDERR] at
org.jboss.ejb.EntityContainer.create(EntityContainer.java:337)
13:35:57,189 ERROR [STDERR] at
org.jboss.ejb.Container.invoke(Container.java:790)
13:35:57,190 ERROR [STDERR] at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055)
13:35:57,192 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,193 ERROR [STDERR] at
org.jboss.system.ServiceController$ServiceProxy.invoke
(ServiceController.java:
867)
13:35:57,195 ERROR [STDERR] at $Proxy0.create(Unknown Source)
13:35:57,196 ERROR [STDERR] at
org.jboss.system.ServiceController.create(ServiceController.java:271)
13:35:57,198 ERROR [STDERR] at
java.lang.reflect.Method.invoke(Native Method)
13:35:57,200 ERROR [STDERR] at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke
(ReflectedMBeanDispatcher.java:284)
13:35:57,202 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,203 ERROR [STDERR] at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
13:35:57,204 ERROR [STDERR] at $Proxy19.create(Unknown Source)
13:35:57,206 ERROR [STDERR] at
org.jboss.ejb.EjbModule.createService(EjbModule.java:392)
13:35:57,207 ERROR [STDERR] at
org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134)
13:35:57,209 ERROR [STDERR] at
java.lang.reflect.Method.invoke(Native Method)
13:35:57,210 ERROR [STDERR
Re: [JBoss-dev] Re: Wrong credentials passed to getConnection!
Your change below fixes the problem. I checked out clean copies of these
files to make sure.
On Wednesday, May 1, 2002, at 03:07 PM, David Jencks wrote:
On 2002.05.01 00:54:02 -0400 Stephen Coy wrote:
I was beginning to think that I was talking to myself here :-)
It looks like
org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.matchManagedConnections
has the same problem.
Looking at the code I think my suggestion will be enough. The
properties
stored in the LocalManagedConnection are the ones we constructed, we
sent a
copy to Oracle and we forgot about them.
david
I will make this change and let you know. At the moment, I changed the
above function plus LocalManagedConnection to compare the user and
password properties for equality instead.
On Wednesday, May 1, 2002, at 02:44 PM, David Jencks wrote:
I was assuming that a driver would not change the properties passed to
it
on a getConnection(properties) call, but I was WRONG!! Oracle in their
infinite wisdom is adding some more properties.
Can you check if changing line 115 of LocalManagedConnectionFactory to
Connection con =
getDriver().connect(internalGetConnectionURL(),
new Properties(props));
fixes the problem?
Thanks
david jencks
On 2002.04.30 23:59:29 -0400 Stephen Coy wrote:
Futher investigation reveals the following code in jboss-
all/connector/src/main/org/jboss/resource/adapter/jdbc/local/LocalManagedConnection.
java:
private void checkIdentity(Subject subject, ConnectionRequestInfo
cri)
throws ResourceException
{
Properties newProps = mcf.getConnectionProperties(subject,
cri);
if (!props.equals(newProps))
{
props.list(System.err);
newProps.list(System.err);
throw new ResourceException(Wrong credentials passed to
getConnection! );
} // end of if ()
}
You can see that I've added some debugging statements which reveal:
13:51:32,730 ERROR [STDERR] -- listing properties --
13:51:32,731 ERROR [STDERR] user=steve
13:51:32,733 ERROR [STDERR] password=
13:51:32,733 ERROR [STDERR] dll=ocijdbc9
13:51:32,735 ERROR [STDERR] protocol=thin
13:51:32,735 ERROR [STDERR] -- listing properties --
13:51:32,735 ERROR [STDERR] user=steve
13:51:32,738 ERROR [STDERR] password=
13:51:32,770 ERROR [EntityContainer] Exception in service lifecyle
operation: create
so I think it's fair to assume that it is unreasonable to compare
these
property lists for equality.
On Wednesday, May 1, 2002, at 01:40 PM, Stephen Coy wrote:
I'm running the current Branch_3_0 code and the above message has
started appearing in the last few days when deploying my ejb jar
file.
I have an Oracle DS setup as per the example in jboss-
all/connector/src/etc/example-config/oracle-service.xml and the
appropriate security realm set up in login-config.xml. What could
have
changed that would stop this from working?
Here's the console output:
13:35:57,139 ERROR [EntityContainer] Exception in service lifecyle
operation: create
13:35:57,144 ERROR [STDERR] java.sql.SQLException: ResourceException
javax.resource.ResourceException: Wrong credentials passed to
getConnection!
13:35:57,146 ERROR [STDERR] at
org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection
(LocalDataSource.java:105)
13:35:57,148 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.fixTableName(SQLUtil.java:38)
13:35:57,148 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.init
(JDBCEntityBridge.java:103)
13:35:57,184 ERROR [STDERR] at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.create
(JDBCStoreManager.java:
333)
13:35:57,186 ERROR [STDERR] at
org.jboss.ejb.plugins.CMPPersistenceManager.create
(CMPPersistenceManager.java:
155)
13:35:57,188 ERROR [STDERR] at
org.jboss.ejb.EntityContainer.create(EntityContainer.java:337)
13:35:57,189 ERROR [STDERR] at
org.jboss.ejb.Container.invoke(Container.java:790)
13:35:57,190 ERROR [STDERR] at
org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055)
13:35:57,192 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,193 ERROR [STDERR] at
org.jboss.system.ServiceController$ServiceProxy.invoke
(ServiceController.java:
867)
13:35:57,195 ERROR [STDERR] at $Proxy0.create(Unknown Source)
13:35:57,196 ERROR [STDERR] at
org.jboss.system.ServiceController.create(ServiceController.java:271)
13:35:57,198 ERROR [STDERR] at
java.lang.reflect.Method.invoke(Native Method)
13:35:57,200 ERROR [STDERR] at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke
(ReflectedMBeanDispatcher.java:284)
13:35:57,202 ERROR [STDERR] at
org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
13:35:57,203 ERROR [STDERR] at
org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174)
13:35:57,204 ERROR [STDERR
[JBoss-dev] CMP2.0 test case coverage
Hi, By looking for usage of jaws.xml files, I think I've uncovered some holes in the test suite: [steve@ws102 src]$ find . -name jaws.xml ./resources/bank/META-INF/jaws.xml ./resources/bankiiop/META-INF/jaws.xml ./resources/bench/ejb/META-INF/jaws.xml ./resources/dbtest/META-INF/jaws.xml ./resources/readahead/META-INF/jaws.xml ./resources/testbean2/META-INF/jaws.xml These tests all exercise CMP1.1, but as far as can see (with a cursory look), there are no equivalent tests for CMP2.0. In particular, I think that we need a CMP2.0 version of dbtest, because this is extremely useful for checking the default standardjbosscmp- jdbc.xml mappings with different databases. Steve Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
I'm willing to tackle this. Do you have any idea what shape you would like? Particular areas to cover? On Tuesday, April 30, 2002, at 04:31 AM, Dain Sundstrom wrote: Yep the main test only use JAWS. I think david was looking at getting these tests to use JAWS and JBossCMP, but I think he got to busy. Do you want to try to get them running under JAWS and JBossCMP? -dain Stephen Coy wrote: Hi, By looking for usage of jaws.xml files, I think I've uncovered some holes in the test suite: [steve@ws102 src]$ find . -name jaws.xml ./resources/bank/META-INF/jaws.xml ./resources/bankiiop/META-INF/jaws.xml ./resources/bench/ejb/META-INF/jaws.xml ./resources/dbtest/META-INF/jaws.xml ./resources/readahead/META-INF/jaws.xml ./resources/testbean2/META-INF/jaws.xml These tests all exercise CMP1.1, but as far as can see (with a cursory look), there are no equivalent tests for CMP2.0. In particular, I think that we need a CMP2.0 version of dbtest, because this is extremely useful for checking the default standardjbosscmp- jdbc.xml mappings with different databases. Steve Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CMP2.0 test case coverage
For what its worth, here's my hand reconfig notes for changing the
default DS to Oracle prior to running the test suite:
Oracle Setup for JBoss Unit Test Suite
1. Add the following to auth.conf
OracleDbRealm {
//
// Security domain for new jca framework.
// One per ManagedConnectionFactory are required.
org.jboss.resource.security.ConfiguredIdentityLoginModule required
principal=jbtest
userName=jbtest
password=jbtest
managedConnectionFactoryName=jboss.jca:service=LocalTxCM,name=OracleDS
;
};
2. Add oracle-service.xml to deploy directory
3. Change the jndi name in hsqldb-service.xml to (say) hsqldbDS
4. Change the jndi name in oracle-service.xml to DefaultDS
5. Ensure that conf/standardjbosscmp-jdbc.xml has up-to-date Oracle
mappings and the
default type mapping points at it
6. Ensure that conf/standardjaws.xml has up-to-date Oracle mappings
and the default
type mapping points at it
Some of this is slightly out of date with the introduction of
login-config.xml, but I think it provides the information that anyone
needs.
On Tuesday, April 30, 2002, at 02:31 PM, David Jencks wrote:
On 2002.04.29 23:35:20 -0400 Dain Sundstrom wrote:
Stephen Coy wrote:
I'm willing to tackle this. Do you have any idea what shape you would
like?
Not sure what that means.
Particular areas to cover?
To start the I'd just like to see the CMP 1.1 tests running under
JBossCMP and JAWS in the unit test suite. Then it would be cool to
have
similar tests that are just modified for CMP 2.0, but that is for
another day. The following tests should run fine in JBossCMP
./resources/bank/META-INF/jaws.xml
./resources/bankiiop/META-INF/jaws.xml
./resources/bench/ejb/META-INF/jaws.xml
./resources/dbtest/META-INF/jaws.xml
./resources/testbean2/META-INF/jaws.xml
This test may not run as readahead is very different in JBossCMP
./resources/readahead/META-INF/jaws.xml
Also, David was looking at changing the config files so the tests could
be run under several databases. To start we just need to remove any
specified datasource or type-mapping elements from the jaws.xml files.
Then we need to figure out how to gets the test code to switch
DefaultDS
and the default type-mapping (datasource-mapping in JBossCMP). Again,
that is for another day.
I think our best bet for this is to use the ant copy/filter task to
replace
tokens where needed. I think it will take building jboss + the
testsuite
for a given db so that standardJaws and standardJbossCmp-jdbc have the
appropriate type mapping. I may have already done this, I can't
remember.
I'll say it again, I think eventually all the ejbs in our tests should
be
built with xdoclet (except perhaps for the ones that intentionally have
errors;-) If I had time to work on this I would be moving the tests to
xdoclet now.
thanks
david jencks
Remember KISS,
-dain
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
I'm also running into a problem that may be related to this. I have a .war (or the .war embedded in a .ear properly referenced in application.xml. Essentially, I have some .properties files jarred into the .war: WEB-INF/ classes/ com/ whitesmiths/ sacha/ web/ Messages_en.properties These are accessible when deployed in the RC1 candidate download available from sf. They are no longer accessible when deployed in the RC1 built from CVS. Something has changed and I think it's now broken. It should not be necessary to have explicit classpath settings in the manifest for this stuff. The same applies to jars installed in WEB-INF/lib. On Friday, April 19, 2002, at 07:12 AM, Larry Sanderson wrote: Applications within an ear file will only get deployed if: 1) They are referenced from an application.xml module tag (rars,ejbs,wars, and client jars) 2) They are spcified in a META-INF / Class-Path entry of one of the the deployed applications from step 1. (See http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#JAR%20Manifest) Have you tried step 2 above? If so, let me know and I will try to reproduce it. -Larry It doesn't seem to be fixed. I just (18-Apr-2002 21:00 MET) compiled the latest code from Branch_3_0 and ran into the same problems again. I, too, bundled struts.jar with my EAR. I could only make it work by copying struts.jar to JBoss' lib directory. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
1. The resource is being accessed from a struts taglib. So I guess that means it is being accessed from a jar installed in WEB-INF/lib 2. It has been working for sometime (weeks) in JBoss HEAD up until a day or two ago. 3. I would not expect .war classes to be able to see struts if it is in a jar next to the .war. The struts.jar is supposed to be in WEB- INF/lib *inside* the .war. 4. Actually, it was Saturday here when you wrote this! On Saturday, April 20, 2002, at 01:42 AM, Larry Sanderson wrote: I'm also running into a problem that may be related to this. I have a .war (or the .war embedded in a .ear properly referenced in application.xml ... OK - A few questions. From where are you accessing this resource (i.e. the location of the directory or jar file where the accessing class lives). Is it in your WEB-INF/lib, WEB-INF/classes, sitting next to the war file? I'm going to assume that it is in the WEB-INF/lib directory, since the only change I made since RC1 would affect nested archives (usually located in WEB-INF/lib). Second question... Have you ever tried this scenario with 3.0 beta, prior to RC1? I am interested to know if that worked. From what I can tell from the class history, I don't think this would have worked, but I may be mistaken. A brief explanation of the classloader hierarchy: JBoss has a custom ClassLoader called the UnifiedClassLoader. ClassLoaders normally have a parent-child hierarchy, such that a child ClassLoader can see all classes loaded by the parent, but the parent cannot see those classes loaded by the child. The UnifiedClassLoader throws that concept out the window. Any class loaded by a UnifiedClassLoader can see every other class loaded by another UnifiedClassLoader, regardless of the parent child relationship. My original changes (in the RC1 release): The problem with war files is that Jetty and Tomcat use their own Classloaders to load up the war file. (This includes the lib and classes directories within WEB-INF). Since they are not using the UnifiedClassLoader, all of JBoss's normal classes can not see any of the files within the web archive. So, if struts.jar was located next to the war file, it would be loaded by JBoss and the UnifiedClassLoader, and when it came time to access your struts Actions (within your war file's lib or classes directories), it would get a ClassNotFoundException. This was the original problem on this thread. My most recent change: Since all classes need to be able to see each other, the obvious solution is to use the UnifiedClassLoader to load all classes. The fix I put in since RC1 was released was to use the UnifiedClassLoader on all nested deployable archives. This is (I think) exactly the way things were done prior to my work. The only problem is that it left out the WEB-INF/classes directory. The fix: I just need to load WEB-INF/classes with a UnifiedClassLoader and your problem should be solved. This is a fairly simple fix, and I will get it in today. I need to create some test cases to check all this, but that will have to wait for the weekend (Is it Friday already?) Sorry for the confusion. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-541855 ] Passivation of stateful sess beans fails
Hi, After fixing a bug in my test case I can see that this is now indeed fixed. However, I'm going to be a pain here. I don't think that your test case code in org.jboss.test.JBossTestCase.testLocalInterfacePassivation and org.jboss.test.cts.ejb.StatefulSessionBean proves anything. It only proves that at some point one or both of ejbPassivate/ejbActivate have been called. Before the bug was fixed, the failure was occurring after ejbPassivate was called. In order to properly test that the StatefulSessionBean was passivated and then recreated you need a transient flag that gets set in ejbPassivate. Your non-transient 'wasPassivated' flag will itself be serialised and then reinstated at activation time, but for good measure, you set it again in ejbActivate anyway. Consequently, you can't tell if the bean was ever successfully passivated and then reactivated. The only way to tell is by exploiting the fact that transient members aren't reinstated when the bean is reactivated. Therefore, I think that: 1. org.jboss.test.cts.ejb.StatefulSessionBean.wasPassivated should be transient (and probably renamed - that's why it's just called 'passivationFlag' in my test case). 2. the line containing 'wasPassivated = true;' should be removed from ejbActivate(). For a slightly stronger test, leave the 'wasPassivated' flag as is, and add a second transient field so that you can check that passivation was actually attempted and it succeeded (because the transient field gets reset). Steve Coy On Friday, April 19, 2002, at 02:58 AM, [EMAIL PROTECTED] wrote: Bugs item #541855, was opened at 2002-04-09 22:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=541855group_id= 22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 6 Submitted By: Stephen Coy (scoy) Assigned to: Scott M Stark (starksm) Summary: Passivation of stateful sess beans fails Initial Comment: Section 7.4.1 of the EJB2.0 spec says that EJBLocalHome and EJBLocalObject (amongst others) should be persisted during passivation. The code in org.jboss.ejb.plugins.SessionObjectOutputStream clearly doesn't do this yet. Someone needs to check and ifx this code for EJB2.0 conformance. -- Comment By: Scott M Stark (starksm) Date: 2002-04-18 09:58 Message: Logged In: YES user_id=175228 Fixed on head and the 3.0 branch -- Comment By: Stephen Coy (scoy) Date: 2002-04-17 01:10 Message: Logged In: YES user_id=463096 Doh! I figured out that I can set the cache size to 1. Creating a second session bean causes the first to be passivated. We now have a test that successfully fails. -- Comment By: Stephen Coy (scoy) Date: 2002-04-17 00:17 Message: Logged In: YES user_id=463096 The attached files incorporate test case stateful2 into the JBoss test suite. Please remove any .DS_Store files you find - they're an unfortunate side effect of using MacOS at present. I spent quite some time trrying to configure the container so that the session bean would passivate before the test completed, but failed miserably. However, you can still see the passivation failing when the EJB is undeployed. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=541855group_id= 22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Because there is not yet any code in place to handle the passivation of these objects. If you look in org.jboss.ejb.plugins.SessionObjectOutputStream you can see that it's only the original EJB1.1 stuff. EJBLocalObject and EJBLocalHome are not serializable, and so must be specially handled together with their remote brethren in SessionObjectOutputStream.replaceObject, not to mention the corresponding activation code in SessionObjectInputStream. On Wednesday, April 17, 2002, at 10:41 AM, Jason Dillon wrote: Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Nope. How would you automate testing it? I know it doesn't work because I've observed it in the console log. On Wednesday, April 17, 2002, at 10:58 AM, Jason Dillon wrote: Does the testsuite cover these? --jason Quoting Hunter Hillegas [EMAIL PROTECTED]: I think some part of them is not marked as serializable... From: Jason Dillon [EMAIL PROTECTED] Date: Tue, 16 Apr 2002 17:41:19 -0700 To: Stephen Coy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Damn. I'm usually more careful than that. It must have been late. Anyway, I'm working up a test case which I'll attach to the bug report. On Wednesday, April 17, 2002, at 11:32 AM, Scott M Stark wrote: The silence was most likely due to a poor bug report . There is no selection of which version this applied to and no example demonstrating the problem. Start with a testcase that uses a custom container configuration to set a short passivation timeout. - Original Message - From: Stephen Coy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 5:23 PM Subject: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem in JDBCStartCommand.java
I think that adding a schema name element as described below would be a great idea. At the present moment, I am hacking JDBCStartCommand.tableExists: DatabaseMetaData dmd = con.getMetaData(); rs = dmd.getTables(con.getCatalog(), dmd.getUserName(), tableName, null); But I might point out that for us, this is just for the practical convenience of sharing a single Oracle instance amongst half a dozen developers. I suspect that it's not very portable across dbms's. Adding an optional schema element to jbosscmp-jdbc.xml would certainly resolve my problem in a platform independent way. BTW. I don't think that using: TABLEmyschema.mytable/TABLE will work in the current implementation anyway, because the table name is also used for generating the pk constraint name. The above will yield something like pk_myschema.mytable, which probably won't work. On Tuesday, April 16, 2002, at 02:32 AM, Dain Sundstrom wrote: Yes, it is the same work if you are going to specify both. The real benefit comes from being able to specify schema-name in the defaults section. -dain Ignacio Coloma wrote: I don't see how that is different than using MYSPACE.MYTABLE. Same amount of code for the user, but you would have to support Yet Another Feature. IMHO it's the same to write: SCHEMAmyschema/SCHEMA TABLEmytable/TABLE than TABLEmyschema.mytable/TABLE Do other environments support this? This should be a common problem. As far as I remember Delphi left you alone on this one. On Mon, 2002-04-15 at 15:56, Dain Sundstrom wrote: This looks like a hack to me. Should we consider adding a schema-name element to the table configuration? By this I mean that where ever we have table-name in the jbosscmp-jdbc.xml file we can have an optional schema-name element. Also in the getTables call in we would pass the schema name as the second argument. Does this make since? Does anyone else have an opinion on this? -dain [EMAIL PROTECTED] wrote: Maybe you could take only the last period delimited token (meaning in MYSCHEMA.MYTABLE use MYTABLE) as the tablename when you must be using only a table name, not a qualified tablename. I would expect that most RDBMS products, open or closed source, use this convention of . delimiting tokens in table and column names. Cheers From: Dain Sundstrom [EMAIL PROTECTED] Date: 2002/04/15 Mon AM 10:40:32 EDT To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Problem in JDBCStartCommand.java JL@esial wrote: Hello, I am using JBoss 3.0.0beta2(200204150942) on Win2k SP2. The function tableExists in this class makes the following jdbc call: rs = dmd.getTables(con.getCatalog(), null, tableName, null); I am using DB2 as dbms, and this piece of code will not work if tableName contains a prefix. Why would it have a prefix? Indeed, I have to configure my jbosscmp-jdbc.xml ejb/table mappings like that: table-nameMYSCHEMA.MYTABLE/table-name to get the SQL statements work properly with DB2. But then the tableExists method will always return false since it takes MYSCHEMA.MYTABLE as tableName. JBossCMP tries it's best to autogenerate tables, but it can not solve all problems. I shoot for 80%. If you need an exact mapping, you will have to create the tables by hand (you should also do this before sending the application to production). If you have a *SIMPLE* solution that works on all of the major commercial and all opensource DBs, then I am open to the suggestion/ patch. Is there an easy way to set a tablename prefix or even a schema name in jbosscmp-jdbc.xml ? Right now, I think I will have to patch my own code, but I believe many people out there using DB2 or Oracle might encounter the same problem. I don't think others have this problem, as you are the first to report it as a problem. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem in JDBCStartCommand.java
See annotations below: On Tuesday, April 16, 2002, at 12:10 PM, David Jencks wrote: 1. I agree with you. 2. I've been wondering about something As I recall in Oracle if youre user name = schema name you don't need to prefix table names with the schema name? Yes. The tables in different schemas are completely independent, right? Yes. But I believe that you can have cross-schema relationships. Foreign keys for example can point into different schema. Someone wanted to have users login name translate to schema login... does this happen automatically if you do nothing in Oracle? (this might be my first question again) I think they want each schema to have exactly the same tables. That was me. Because we're sharing a single Oracle instance amongst many developers. The developers are all working on the same product. If one of them adds a cmp field to an entity bean, we don't want that to bring down everyone else. The hack shown below is needed because DatabaseMetaData.getTables() returns results from all schemas that contain a table called tableName if a null schema name is passed. What would happen if one did this? would you need to make sure that no two primary keys in tables of the same name but different schemas were identical? (So the entity beans were distinguished) Is there a convenient way to assure this in Oracle? No. Tables in different schemas are independent of one another and have their own indexes. I believe that adding the schema tags will allow JBoss users to exploit the schema implementation of their favourite database as they see fit, if they so desire. In our situation, we would also need xdoclet support for same. You would also need to be careful with foreign key references. Thanks david jencks On 2002.04.15 20:16:43 -0400 Stephen Coy wrote: I think that adding a schema name element as described below would be a great idea. At the present moment, I am hacking JDBCStartCommand.tableExists: DatabaseMetaData dmd = con.getMetaData(); rs = dmd.getTables(con.getCatalog(), dmd.getUserName(), tableName, null); But I might point out that for us, this is just for the practical convenience of sharing a single Oracle instance amongst half a dozen developers. I suspect that it's not very portable across dbms's. Adding an optional schema element to jbosscmp-jdbc.xml would certainly resolve my problem in a platform independent way. BTW. I don't think that using: TABLEmyschema.mytable/TABLE will work in the current implementation anyway, because the table name is also used for generating the pk constraint name. The above will yield something like pk_myschema.mytable, which probably won't work. On Tuesday, April 16, 2002, at 02:32 AM, Dain Sundstrom wrote: Yes, it is the same work if you are going to specify both. The real benefit comes from being able to specify schema-name in the defaults section. -dain Ignacio Coloma wrote: I don't see how that is different than using MYSPACE.MYTABLE. Same amount of code for the user, but you would have to support Yet Another Feature. IMHO it's the same to write: SCHEMAmyschema/SCHEMA TABLEmytable/TABLE than TABLEmyschema.mytable/TABLE Do other environments support this? This should be a common problem. As far as I remember Delphi left you alone on this one. On Mon, 2002-04-15 at 15:56, Dain Sundstrom wrote: This looks like a hack to me. Should we consider adding a schema-name element to the table configuration? By this I mean that where ever we have table-name in the jbosscmp-jdbc.xml file we can have an optional schema-name element. Also in the getTables call in we would pass the schema name as the second argument. Does this make since? Does anyone else have an opinion on this? -dain [EMAIL PROTECTED] wrote: Maybe you could take only the last period delimited token (meaning in MYSCHEMA.MYTABLE use MYTABLE) as the tablename when you must be using only a table name, not a qualified tablename. I would expect that most RDBMS products, open or closed source, use this convention of . delimiting tokens in table and column names. Cheers From: Dain Sundstrom [EMAIL PROTECTED] Date: 2002/04/15 Mon AM 10:40:32 EDT To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Problem in JDBCStartCommand.java JL@esial wrote: Hello, I am using JBoss 3.0.0beta2(200204150942) on Win2k SP2. The function tableExists in this class makes the following jdbc call: rs = dmd.getTables(con.getCatalog(), null, tableName, null); I am using DB2 as dbms, and this piece of code will not work if tableName contains a prefix. Why would it have a prefix? Indeed, I have to configure my jbosscmp-jdbc.xml ejb/table mappings like that: table-nameMYSCHEMA.MYTABLE/table-name to get the SQL statements work properly with DB2. But then the tableExists method will always return false since it takes MYSCHEMA.MYTABLE as tableName
[JBoss-dev] test-suite build is broken
[execmodules] /Users/steve/Development/jboss- all/testsuite/src/main/org/jboss/test/security/service/SecurityConfig.java: 91: cannot resolve symbol [execmodules] symbol : method setConfig (java.net.URL) [execmodules] location: class org.jboss.security.auth.login.XMLLoginConfig [execmodules] config.setConfig(loginConfig); I gather it should be: config.setConfigURL(loginConfig); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Memory Hog
I'm experiencing similar symptoms on MacOS X 10.1.3. The JVM behaves a bit better though, because JBoss is the only impacted process. Anyway, multiple successive deploys seems to consume memory. At some point I start getting: 11:08:28,432 ERROR [STDERR] java.lang.OutOfMemoryError 11:08:28,433 ERROR [STDERR] no stack trace available messages on the console. Our Win2k developers haven't noticed anything because they usually have to cycle JBoss down and up in order to redeploy anyway, because Windows won't let them overwrite open files. This is from CVS HEAD as of about 24hrs ago BTW, but I think this problem has been around for awhile. Steve C. On Friday, April 12, 2002, at 08:51 AM, Mark Gulbrandsen wrote: FYI, Maybe this has already been posted, but I'll post it again. The deployer on cvs HEAD has a memory problem (I think). If I don't pass any JAVA_OPTS to run.sh via the environment, then redeploying is seriously broken. After the third redeploy *with out fail* jboss runs after every last mb of ram and swap. I have to shut it down before it brings my system to its knees, and I have over 600 mb of ram and 512 mb of swap. If I pass memory options such as -Xms128M -Xmx256m, then no problem exists at all. BTW, this also happens on another box in my office that has 4GB of RAM, but limiting the heap seems to solve it. I'd love to send more information regarding this, but I'm not sure what you (developers) want. I'd look into it, but I can't get into the code just yet (maybe in a few weeks). BTW, we're running SuSE Linux 7.3 with SUN JDK1.3.1. mark@mark:~/usr/src/jboss-cvs/bin java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Memory Hog
I'll see if its possible to accomplish anything with an evaluation copy of one these products... If it proves to be useful, I'll talk the boss into buying it. On Friday, April 12, 2002, at 02:59 PM, Jason Dillon wrote: Do you are anyone else have a profiler like OptimizeIt, or JProbe the time to run your app through it and see what is leaking? --jason Quoting Hunter Hillegas [EMAIL PROTECTED]: These exact symptoms occurred for me today for the first time... I'm on OS X 10.1.3 also... From: Stephen Coy [EMAIL PROTECTED] Date: Fri, 12 Apr 2002 11:23:17 +1000 To: Mark Gulbrandsen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Memory Hog I'm experiencing similar symptoms on MacOS X 10.1.3. The JVM behaves a bit better though, because JBoss is the only impacted process. Anyway, multiple successive deploys seems to consume memory. At some point I start getting: 11:08:28,432 ERROR [STDERR] java.lang.OutOfMemoryError 11:08:28,433 ERROR [STDERR] no stack trace available messages on the console. Our Win2k developers haven't noticed anything because they usually have to cycle JBoss down and up in order to redeploy anyway, because Windows won't let them overwrite open files. This is from CVS HEAD as of about 24hrs ago BTW, but I think this problem has been around for awhile. Steve C. On Friday, April 12, 2002, at 08:51 AM, Mark Gulbrandsen wrote: FYI, Maybe this has already been posted, but I'll post it again. The deployer on cvs HEAD has a memory problem (I think). If I don't pass any JAVA_OPTS to run.sh via the environment, then redeploying is seriously broken. After the third redeploy *with out fail* jboss runs after every last mb of ram and swap. I have to shut it down before it brings my system to its knees, and I have over 600 mb of ram and 512 mb of swap. If I pass memory options such as -Xms128M -Xmx256m, then no problem exists at all. BTW, this also happens on another box in my office that has 4GB of RAM, but limiting the heap seems to solve it. I'd love to send more information regarding this, but I'm not sure what you (developers) want. I'd look into it, but I can't get into the code just yet (maybe in a few weeks). BTW, we're running SuSE Linux 7.3 with SUN JDK1.3.1. mark@mark:~/usr/src/jboss-cvs/bin java -version java version 1.3.1 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24) Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode) ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem in JDBCStartCommand.java
On Monday, April 8, 2002, at 05:35 PM, Georg Schmid wrote: so one could use getSchema() instead of getCatalog() (and don't forget to use getSchemaTerm() :-)). I agree that getSchema() would be handy here. Unfortunately, I don't believe that it exists. There is a getSchemas(), but that's kind of useless in this context. I've patched our code to use dmd.getUserName(), which, as far as I can ascertain, returns exactly what I would expect getSchema() to return anyway. It doesn't seem to effect the unit test suite, and it fixes my problem. My AU0.04$ :-) Steve ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 3 users -- warning of impending configuration change
Probably because I posted from the forum. It seems to be available there. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12301 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Problem in JDBCStartCommand.java
The function [i]tableExists[/i] in this class makes the following jdbc call: rs = dmd.getTables(con.getCatalog(), null, tableName, null); This call seems to return a result if tableName exists in [i]any[/i] schema in the database. This is causing us some problems because we have each of our developers using the same Oracle8 database, but their own schema/userid. This was all working fine, until the relevation earlier this week that we should specify table names in uppercase. Now that we are doing this, noone can create new CMP tables anymore, because JBoss thinks it already exists (albeit in someone else's schema). Unfortunately, my knowledge of JDBC's idea of catalogs and schemas is weak at the moment, so I'm reluctant to record this as a bug just now. It may even be an Oracle permissions thing. Any advice either way would be appreciated. This is in the JBoss 3.0 CVS HEAD as of 24 hours ago or so. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12265 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] if you're having trouble building
I'd just like to add that I had to do a completely clean checkout before I could build too. That's from CVS just a few minutes before this post. No combination of clean or clobber would allow a build from a cvs update -dP. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=10665 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
