Bugzilla – Full Text Bug Listing
| Summary: | DBWSBuilder: add new API to manage list of paths to find JDBC driver class | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Mike Norman <michael.norman> |
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipselink.dbws-inbox, neil.hauge, tranle1 |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Mike Norman
<?xml version="1.0" encoding="UTF-8"?> <dbws-builder xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <properties> <property name="projectName">testSql</property> ... database properties <property name="driver">oracle.jdbc.OracleDriver</property> </properties> <driver-paths> <path>some path to a jar or zip</path> <path>another path</path> <path>what about http: or file: URLs?</path> <path>what about 'special' characters, spaces - do these entries need to be CDATA sections?</path> </driver-paths> <sql or <table ... name=... </sql> </dbws-builder> In the DBWSBuilder's model Project, use a custom attribute accessor to convert this to an ArrayList of Strings. For the programmable API, add set- and get-ter's to the driversPath ArrayList. At build time, if the driversPath list is not empty, then a URLClassLoader is created from the strings and this is used to find the JDBC driver class Shaun Smith said in an email "I can see having the driver name and connection URL in the builder file but why wouldn't you, in a non-IDE environment, simply use the classpath to find driver classes? The problem we're addressing in the IDE is that the classpath is not sufficient. So I think you need API to set the driver paths but don't need support for for static declaration of the driver path. It will just result in brittle builder config files." I have spent the last 3 days getting very VERY frustrated by OSGi classloader rules. The issue boils down to this: One of the main parts of dealing with JDBC drivers is setting the EclipseLink DatabasePlatform. In order to create an instance of a platform class - say for example, org.eclipse.persistence.platform.database.oracle.Oracle9Platform, we must deal with the required dependent classes. Oracle9Platform is located in a 'fragment' bundle that is 'hosted' by the core Eclipse bundle org.eclipse.persistence.core_2.x.y.vYYYmmdd-rbldno.jar. Oracle9Platform depends on classes in the oracle.sql package which needs to be found somehow by the OSGi classloader for said EclipseLink core bundle. OSGi provides many ways to specify where these dependent classes can be found: entries in a MANIFEST.MF file, through a target platform, in an application's config.ini file, etc. However, the one thing an application (in this case the application is Dali) cannot do is resolve the dependency at runtime - say by asking the user to provide a path (or paths) to a jar on the user's local filesystem. I have looked at any and all possibilities and consulted with Tom Ware and Mike Keith (who in turn asked for Shaun's advice) and we are in agreement - it can't be done. So with respect to DBWSBuilder using a list of paths provided by some external agent using a setPaths API, I don't see how that can be made to work. Of course, when DBWSBuilder is used from the command-line, it can be made to work easily; however it would be just as simple for the list of user-provided paths to be added to the CLASSPATH (in the .cmd or .sh script that starts the utility); thus the setPaths API isn't needed. My only suggestion is to treat this in a similar fashion to how the Eclipse IDE handles downloaded bundle updates. An instance of the IDE (with the Dali plugin) is running and the user is prompted for the path (or paths) to the dependent JDBC driver jar. The MANIFEST.MF file for the EclipseLink core bundle is modified to add entries to the Bundle-ClassPath: attribute and then the IDE is re-started. Neil replied in an email: Thanks for the detailed update Mike. We will consider the alternatives and head down a different path. I think ultimately (most likely in a future release) we want to use the existing setConnection() API, but for now we will either fall back to using an external launcher or figure out a low-cost, reasonable user story involving the configuration of the connection within the IDE, which is where we ultimately want to be. The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |