Hi David

I¹m OK with the filter idea you just explained, I still think it¹s more
useful than the jar list itself, but at least you will have all you need.

About the class it¹s more related to how the classloaders will interact and
how my application will be able to determine wich Driver version should use
as you have more than one available.

Imagine you create 2 datasources, one pointing to the classes12.jar for the
oracle8i and other pointing to the ojdbc14.jar for oracle10g.
Then you deploy one application that uses both datasources.
Then you have some Driver extension code in your application that should
extend the oracle10g driver... How your application classloader will be able
to resolve wich driver it¹s going to load?

Regards,
Daniel 


On 19/4/07 21:41, "David Jencks" <[EMAIL PROTECTED]> wrote:

> I don't seem to be explaining what I have in mind very well.  I was thinking
> of a text entry box on the db wizard page where you;d type in a fully
> qualified class name and a button you'd then push, at which point only jars
> containing that class would appear in the list of jars. You could then select
> the one you want as a dependency of the plan you are constructing.   I don't
> understand the purpose of the class you show below.
> 
> So for instance you could type in "com.foo.BarXADataSourceImpl" and you'd get
> a list of all the different FooBar db driver jars.
> 
> thanks
> david jencks
> 
> On Apr 19, 2007, at 9:58 AM, Daniel Alheiros wrote:
> 
>>  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.
> 
> 



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.
                                        

Reply via email to