Checking for required classes from within Derby?

[Army <qo...@gmail.com>]

As part of my work for DERBY-688 I've made some slight changes to the XML 
operators that were added in DERBY-334 and I've also added a new operator, XMLQUERY.

These operators depend on the presence of classes that are technically 
"external" to Derby.  Or more specifically, they expect that the user's 
classpath will include 1) an implementation of JAXP (such as Xerces or Crimson) 
and 2) Apache Xalan.

In preparation for the 10.2 exposure of the XML datatype and corresponding 
operators I want to add checks in the Derby code to see if the required classes 
exist and to throw a more user-friendly error if they don't (instead of some 
ClassNotFoundException (or worse) in the middle of processing, which isn't very 
intuitive).  I currently have code working that does this by calling 
Class.forName(...) and passing in the name of one of the required classes, and 
then catching the resultant exception (if there is one) and converting it to 
something more meaningful.

Ex:

             try {

                 /* If the w3c Document class exists, then we
                  * assume a JAXP implementation is present in
                  * the classpath.
                  *
                  * Note: The JAXP API and implementation are
                  * provided as part the JVM if it is JDBC 3.0 or
                  * greater.
                  */
                 Class.forName("org.w3c.dom.Document");
                 try {

                     /* If the XPath class exists, then we assume that our XML
                      * query processor (in this case, Xalan), is present in the
                      * classpath.
                      */
                     Class.forName("org.apache.xpath.XPath");

                 } catch (java.lang.ClassNotFoundException e) {
                 // couldn't find query processor (Xalan).
                     <user-friendly error processing>
                 }

             } catch (java.lang.ClassNotFoundException e) {
             // couldn't find JAXP parser.
                 <user-friendly error processing>
             }

While this works, I can't help but wonder if Derby has some sort of existing 
mechanism/utilities to check for the existence of required classes in a cleaner 
(and perhaps more correct?) way.

Does anyone know if such a utility/mechanism exists, and if so, can I get some 
pointers to code/documentation?  I admit I haven't done much searching of the 
code yet; I figured I'd start with the list and maybe save some time...

Thanks much,
Army

Re: Checking for required classes from within Derby?

[Army <qo...@gmail.com>]

Daniel John Debrunner wrote:

> Derby's loading of modules from modules.properties has a mechanism where
> a module is not loaded if its declared list of classes are not loadable.
> 
<snip>
> 
> Otherwise the utility class
> org.apache.derby.iapi.services.loader.ClassInspector  has some methods,
> you could add a new utility method there.

Thanks for the suggestions (and quick reply), Dan.  I'll start with these and 
see which approach seems most appropriate.

> PS.
> Tthis code comment is technically incorrect, JDBC 3 has nothing to
> do with JAXP, JAXP api is driven by the JDK level not the JDBC level.

Corrected.

Thanks again,
Army

Re: Checking for required classes from within Derby?

[Daniel John Debrunner <dj...@apache.org>]

Army wrote:

> As part of my work for DERBY-688 I've made some slight changes to the
> XML operators that were added in DERBY-334 and I've also added a new
> operator, XMLQUERY.
[snip]
> While this works, I can't help but wonder if Derby has some sort of
> existing mechanism/utilities to check for the existence of required
> classes in a cleaner (and perhaps more correct?) way.
> 
> Does anyone know if such a utility/mechanism exists, and if so, can I
> get some pointers to code/documentation?  I admit I haven't done much
> searching of the code yet; I figured I'd start with the list and maybe
> save some time...
Derby's loading of modules from modules.properties has a mechanism where
a module is not loaded if its declared list of classes are not loadable.

E.g.

derby.module.jdbcJ2=org.apache.derby.jdbc.Driver20
derby.env.jdk.jdbcJ2=2
derby.env.classes.jdbcJ2=java.sql.Driver

Only load the org.apache.derby.jdbc.Driver20 module if java.sql.Driver
is loadable.

So maybe you could look at that code to see if it helps.

Otherwise the utility class
org.apache.derby.iapi.services.loader.ClassInspector  has some methods,
you could add a new utility method there.

Dan.
PS.
Tthis code comment is technically incorrect, JDBC 3 has nothing to
do with JAXP, JAXP api is driven by the JDK level not the JDBC level.

                 * Note: The JAXP API and implementation are
                 * provided as part the JVM if it is JDBC 3.0 or
                 * greater.