Interesting...
So if my application depends on an OracleDriver or other vendor specific
implementations how my application will be instructed to refer to the
specific implementation (jar) as my class import one of those. How can it
resolve the reference to the correct jar?
An example class:
import java.sql.Connection; import java.sql.Driver; import
java.sql.DriverManager; import java.sql.SQLException; import
oracle.jdbc.OracleDriver; /** * @author daniel */ public class WeirdTest {
/** * @param args */ public static void main(String[] args) {
try { Driver driver = new OracleDriver();
DriverManager.registerDriver(driver); Connection conn =
DriverManager.getConnection("jdbc:oracle:thin:@noldb03:1521:cpslive",
"nol_web_page_builder", "nolwebpagebuilder");
System.out.println(conn.getMetaData()); } catch (SQLException
e) { e.printStackTrace(); } } }
Regards
On 19/4/07 15:51, "David Jencks" <[EMAIL PROTECTED]> wrote:
>
> On Apr 19, 2007, at 2:08 AM, Daniel Alheiros wrote:
>
>> Sorry for the ignorance, but I'm a but confused about this jar
>> selection...
>> Does it allows me to have more than one driver version for the same
>> vendor
>> (like having a Oracle 8i and Oracle 10g drivers at same time being
>> used by
>> different datasources)?
>
> yes.
>
>> If not, what is the point in selecting the JAR in
>> this form?
>>
>> Does the Geronimo's classloaders allows me to have "one" class in
>> different
>> versions available? I don't believe it could be managed safely, so
>> I believe
>> it doesn't.
>
> not in the same classloader, but just as with the datasources this
> works fine with the "same" class in different classloaders.
>>
>> I like the idea of having a list containing eventual implementation
>> options,
>> because it is much easier to take a look in an existing environment
>> and be
>> aware of what drivers are available and avoid eventual
>> incompatibilities
>> changing drivers (like Oracle 8i and Oracle 9 or 10g drivers)
>
> Collecting the jars needed for a particular driver to work can't be
> done in any automatic uniform way at the moment AFAIK. So we either
> have to show all the jars and let the user pick or require that some
> person figure out and install the metadata for each driver. My
> experience is that a metadata based solution will never be kept up to
> date.
>
> I thought that a search feature that would find all the jars
> containing a particular class, given the fully qualified class name,
> was a reasonable compromise between having to look through all the
> jars with no clue about whats inside and hiding most of the jars
> based on what is sure to be out of date information.
>
> thanks
> david jencks
>
>>
>> Regards
>>
>>
>> On 18/4/07 19:28, "Aaron Mulder" <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Just remember that one of the main reasons that there's an awkward
>>> display of tons of JARs now is that the DB2 driver (did? does?)
>>> require 3 JARs to all be added in order to function, and only one of
>>> those has any kind of driver implementation AFAIK. (I think one is a
>>> license and not sure about the other.) I think there is at least one
>>> other multi-JAR driver out there too.
>>>
>>> I think it would be nice if we showed a single combo box, perhaps
>>> with
>>> just the driver JARs listed, and then had a checkbox where if you
>>> clicked it then the page would adjust to let you select multiple
>>> arbitrary JARs instead.
>>>
>>> Thanks,
>>> Aaron
>>>
>>> On 4/18/07, Daniel Alheiros <[EMAIL PROTECTED]> wrote:
>>>> Well anyway, if you are going to filter by the class, you still
>>>> have the
>>>> "problem" of not seeing all its dependent classes/jars... But I
>>>> really think
>>>> it shouldn't be a big deal in this context.
>>>>
>>>> Talking about the performance hit related to this kind of
>>>> filtering, it can
>>>> be avoided if you keep track of those classes since you install
>>>> it into your
>>>> repository folder. What do you think about it?
>>>>
>>>> This initial idea in terms of filtering aims to make the
>>>> information shown
>>>> really useful to the console user (system operators and
>>>> developers)...
>>>>
>>>> And instead of just filtering the java.sql.Driver
>>>> implementations, it could
>>>> be instructed to look at XAResource implementations as well...
>>>>
>>>> Regards
>>>>
>>>>
>>>> On 18/4/07 16:17, "David Jencks (JIRA)" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>>
>>>>> [
>>>>> https://issues.apache.org/jira/browse/GERONIMO-3106?
>>>>> page=com.atlassian.jira.
>>>>> pl
>>>>> ugin.system.issuetabpanels:comment-tabpanel#action_12489781 ]
>>>>>
>>>>> David Jencks commented on GERONIMO-3106:
>>>>> ----------------------------------------
>>>>>
>>>>> What we have now is surely annoying and hard to use, but there
>>>>> are at least
>>>>> 2
>>>>> problems with the proposal:
>>>>>
>>>>> 1- it wouldn't show a jar that had an xa-only datasource
>>>>> implementation with
>>>>> no Driver implementation
>>>>> 2- it wouldn't show utility jars that might be needed by some
>>>>> drivers
>>>>>
>>>>> So, an option to filter the jars might be useful but it would
>>>>> certainly slow
>>>>> down the ui and you'd need to be able to turn it off.
>>>>>
>>>>> Perhaps a "find the jars containing this class" button would be
>>>>> useful?
>>>>>
>>>>>> When you are in the Create Database Pool wizard the jar driver
>>>>>> list could
>>>>>> show only jars containing Driver implementations
>>>>>> ------------------------------------------------------------------
>>>>>> ---------
>>>>>> --
>>>>>> ---------------------------------------------
>>>>>>
>>>>>> Key: GERONIMO-3106
>>>>>> URL: https://issues.apache.org/jira/browse/
>>>>>> GERONIMO-3106
>>>>>> Project: Geronimo
>>>>>> Issue Type: Improvement
>>>>>> Security Level: public(Regular issues)
>>>>>> Components: console
>>>>>> Affects Versions: 2.0-M3
>>>>>> Reporter: Daniel Alheiros
>>>>>> Priority: Minor
>>>>>>
>>>>>> The combo actually shows all the repository jars but could be
>>>>>> organized in
>>>>>> an
>>>>>> easier way if are shown only the repository jars containing
>>>>>> java.sql.Driver
>>>>>> implementations.
>>>>
>>>>
>>>> http://www.bbc.co.uk/
>>>> This e-mail (and any attachments) is confidential and may contain
>>>> personal
>>>> views which are not the views of the BBC unless specifically stated.
>>>> If you have received it in error, please delete it from your system.
>>>> Do not use, copy or disclose the information in any way nor act
>>>> in reliance
>>>> on it and notify the sender immediately.
>>>> Please note that the BBC monitors e-mails sent or received.
>>>> Further communication will signify your consent to this.
>>>>
>>>>
>>>>
>>
>>
>> http://www.bbc.co.uk/
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless
>> specifically stated.
>> If you have received it in error, please delete it from your system.
>> Do not use, copy or disclose the information in any way nor act in
>> reliance on it and notify the sender immediately.
>> Please note that the BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
>>
>
http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal
views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on
it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
