Menu
▾
▴
Re: [Bsf4oorexx-devel] O.K., *serious* request for feedback, what to do? (Re: Request for feedback ...
|
From: Rony G. F. <Ron...@wu...> - 2014-09-12 10:02:42
|
Hi Chip, thank you for your feedback! On 11.09.2014 21:47, Chip Davis wrote: > JDBC bug report? Possibly. Still have to check-out the reason for the DriverManager doing what it is doing (makes sense in the context of J2EE, but it may be the case that this particular use-case was not foreseen or that there is some implementation bug in DriverManager). Probably I will first ask a question in the Apache derby-user mailing lists (have subscribed yesterday and was about to write an e-mail to the list, when I got the idea to move derby.jar to the Java extension directory as well, then becoming able to focus on the DriverManager). Cheers, ---rony > On 9/11/2014 3:12 PM Rony G. Flatscher said: >> Hmm, >> >> probably have found the culprit: java.sql.DriverManager. The >> documentation states: "When the method |getConnection| is called, the >> |DriverManager| will attempt to locate a suitable driver from amongst >> those loaded at initialization and those loaded explicitly using the >> same classloader as the current applet or application.". Cf. eg. >> <http://docs.oracle.com/javase/7/docs/api/java/sql/DriverManager.html>. >> >> Using the extension class loader would not be able to find classes >> outside the java.ext.dirs. So probably this is the reason for the >> observed behaviour. It is a pecularity (maybe with a good reason) of >> the DriverManager. >> >> It is not a problem of putting the BSF jar into the Java extension >> directory per se. However, one needs to document this with the >> jdbc.jrexx sample such that users know what they need to be aware of. >> This also means, that JDBC access is only possible, if the JDBC driver >> is located in the Java extension directory as well, which might not be >> an option in some installations. >> >> Any thoughts, comments? >> >> ---rony >> >> >> >> >> >> On 11.09.2014 20:04, Rony G. Flatscher wrote: >>> Hi there, >>> >>> have been trying to nail down the cause of the JDBC-related error >>> when moving the BSF4ooRexx jar to one of the Java extension directories. >>> >>> It turns out, without a reason that I could find researching the >>> internet, that the JDBC driver has that reported problem, when being >>> loaded via a class from the extended directory. >>> >>> Classes that get loaded from the extended ("optional") packages get >>> processed with an extension class loader, whereas classes from >>> applications and classpath get loaded with an application class >>> loader. Cf. e.g. >>> <http://docs.oracle.com/javase/tutorial/ext/basics/load.html>, >>> <http://stackoverflow.com/questions/5039862/classpath-vs-java-ext-dirs> >>> near the bottom. >>> >>> It seems to be the case, that moving the BSF jar into a Java >>> extension directory works for all BSF4ooRexx samples in the >>> "samples" directory of BSF4ooRexx, covering practically all use >>> cases, the sample "samples\ReneJansen\jdbc.jrexx" does *not* work, >>> rather the reported Java exception with a meaningless message is >>> created. >>> >>> The test script was run with Apache derby which is installed with >>> Java. The classpath points to the derby.jar. The derby.log file is >>> empty (which is really a pity as there are no clues whatsoever what >>> the problem might be). >>> >>> Anyway, after researching the Internet without finding any clues I >>> started to experiment with all sorts of Java version (from Java 1.4 >>> up to 1.7/7) and then started to move the BSF jar to the classpath >>> (then jdbc.jrexx works), moving it to the different Java extension >>> directories (does not make a difference, the error occurs). Finally, >>> I moved derby.jar to the extension directory, and low and behold, it >>> worked! >>> >>> It seems that JDBC is quite peculiar. Up to Java 1.6/6 one had to >>> load the jdbc driver class and invoke the newInstance method. This >>> is presumably because otherwise the JDBC driver would not get >>> initialized appropriately. >>> >>> My take is (but at this stage it is merely a guess), that this >>> problem occurs for JDBC driver classes only. For unknown reasons the >>> JDBC drivers need to use the same class loader as the class that >>> loads them. A mixture of application and extension class loader in >>> this particular instance seems to not work. If the BSF jar and the >>> JDBC jar are on the classpath only (using a >>> sun.misc.Launcher$AppClassLoader), it works, and if the jars are >>> both in the extension directory (using a >>> sun.misc.Launcher$ExtClassLoader), it works as well (though not >>> tested yet with HSQL etc.). >>> >>> --- >>> >>> Three questions: >>> >>> * Is there anyone who is able to shed some more light on this JDBC >>> related (it seems) issue? >>> >>> * Is anyone aware of other important Java infrastructures that >>> pose such restrictions on their classes? >>> >>> * What do you think about >>> >>> o Installing the BSF jar into the operating system Java >>> extension directory, such that Java application (e.g. >>> JavaPlugin for browsers, OpenOffice, etc.) get access to the >>> installed BSFooRexx which otherwise (e.g. in the case of the >>> JavaPlugin for browsers) would not be possible at all or (in >>> the case of OpenOffice) mandates a full copy of BSF4ooRexx >>> to be installed for the application, despite BSF4ooRexx >>> being already installed on the machine >>> >>> o Adding a comment to the jdbc.jrexx example that the JDBC >>> drivers need to go into the Java extension directory in >>> order to work. Access to databases via JDBC is IMHO a must >>> for professional deployments. >>> >>> As a scripting language (thinking not only of BSF4ooRexx, but also >>> of NetRexx and the like) are cross-platform gimmicks, I think the >>> support should go into the Java extension directory. >>> >>> ---rony >>> >>> >>> >>> On 10.09.2014 21:14, Rony G. Flatscher wrote: >>>> Hi there, >>>> >>>> one clarification, one retract. >>>> >>>> On 10.09.2014 13:50, Rony G. Flatscher wrote: >>>>> it used to be the case that BSF4Rexx installed the jar-files into the Java-extension directory. >>>>> However (due to a bug that I found years later), loading JDBC-drivers failed, such that instead the >>>>> jar-files got listed on CLASSPATH. >>>> Retraction: putting the BSF4ooRexx-jar-files into the "extension" >>>> directory, the error with creating a connection object from the >>>> JDBC driver (just tested it with derby) will yield the error "No >>>> suitable driver found" when running "samples/ReneJansen/jdbc.jrexx": >>>> >>>> RexxDispatcher.java: Throwable of type 'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx: >>>> getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9: >>>> *-* Compiled routine BSF >>>> Error 40 running F:\work\svn\bsf4oorexx\trunk\samples\ReneJansen\jdbc.jrexx line 46: Incorrect call to routine >>>> Error 40.900: BSF4ooRexx/routine/BSF(), error 3: Java exception occurred: [org.apache.bsf.BSFException: /// Java-exception (RexxAndJava) occurred: [java.lang.reflect.InvocationTargetException], getCause(): [java.sql.SQLException: No suitable driver found for jdbc:derby:derbyDB;create=true] \\\ >>>> BSF4ooRexx subfunction "invoke": object 'java.lang.Class@d24e3f' - method [GETCONNECTION], method not found or error (exception) executing method!]] >>>> >>>> So there is something different for JDBC, if it gets loaded in this >>>> setup, where the BSF4ooRexx-jar-file is in the Java extension >>>> directory. >>>> (The same program runs without an error, if putting the >>>> BSF4ooRexx-jar-file on CLASSPATH instead.) >>>> >>>> Thankful for any hints that might lead to solving this particular >>>> nasty problem! >>>> >>>> (All other BSF4ooRexx programs so far, were able to run, when >>>> having the BSF4ooRexx-jar-file in the Java extension directory.) >>>> >>>> >>>>> In the Java world, for security reasons, the CLASSPATH environment variable does not get honored >>>>> under special situations (e.g. when running a Java applet, the CLASSPATH gets eradicated, but also >>>>> in the case of Apache OpenOffice, where a proper Java class loader unsets the CLASSPATH environment >>>>> variable). This is done usually for security considerations. >>>>> >>>>> Also, adding a jar-file (Java classes) into the Java extension directory causes these classes to be >>>>> found before those that may have been found if searching them via CLASSPATH, so outdated classes, >>>>> corrected classes might not "make it" unless they overwrite those in the extension directories. >>>>> >>>>> One more problem can be that updating Java and having chosen the wrong Java-extension directory >>>>> would remove one owns jar-files, losing access to those extension classes, once a Java update takes >>>>> place. To forgo this problem Sun introduced (not sure in which version) a sort of a "user-related" >>>>> extension directory that updated Java installations would not change, but keep on using. >>>> Clarification: >>>> >>>> * the second extension directory got introduced with Java 1.6/6 >>>> (according to tests on Windows), >>>> >>>> * the Java property "java.ext.dirs" denotes two directories >>>> o one being the installation directory of the current Java >>>> o the second one being a directory which may not exist at >>>> all; hence, before installing into this directory one needs >>>> to check its existence and create it, if necessary >>>> >>>> Cf. >>>> <http://docs.oracle.com/javase/6/docs/technotes/guides/extensions/spec.html>, >>>> section "Installed Optional Packages". >>>> >>>>> There are other problems that may be related directly or indirectly to using the Java extension >>>>> directory. However, this extension mechanism is there for a good reason: allowing to extend Java, if >>>>> one has infrastructural (i.e. cross-application) related needs, demands. >>>>> >>>>> --- >>>>> >>>>> Adding classes/jar-files to the Java extension directory makes these classes actually a part of the >>>>> Java installation. As a result there is no need to list them in CLASSPATH and wherever Java is being >>>>> employed those extension-classes are available as well. >>>>> >>>>> Adding access to a scripting language is clearly a cross-application, an infrastructural >>>>> installation. This would alleviate one to add the BSF4ooRexx jars to jar-files meant for applets or >>>>> for applications like Apache OpenOffice that employs its own class loader, that intentionally >>>>> ignores CLASSPATH, and the like. >>>>> >>>>> Hence I would like to install the BSF4ooRexx jar-file(s) into the user extension directory in the >>>>> future, if no one objects with good reasons. >>>>> >>>>> Any feedback (positive/negative) highly welcome! >>>>> >>>>> ---rony >>>> It would be great if someone had an idea about the JDBC-problem >>>> mentioned above. Any idea highly appreciated! >>>> >>>> ---rony >> >> >> ------------------------------------------------------------------------------ >> Want excitement? >> Manually upgrade your production database. >> When you want reliability, choose Perforce >> Perforce version control. Predictably reliable. >> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >> >> >> >> _______________________________________________ >> Bsf4oorexx-devel mailing list >> Bsf...@li... >> https://lists.sourceforge.net/lists/listinfo/bsf4oorexx-devel >> > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > Bsf4oorexx-devel mailing list > Bsf...@li... > https://lists.sourceforge.net/lists/listinfo/bsf4oorexx-devel -- -- __________________________________________________________________________________ Prof. Dr. Rony G. Flatscher Department Informationsverarbeitung und Prozessmanagement Institut für Betriebswirtschaftslehre und Wirtschaftsinformatik D2-C 2.086 WU Wien Welthandelsplatz 1 A-1020 Wien/Vienna, Austria/Europe http://www.wu.ac.at __________________________________________________________________________________ |