You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "David Jencks (JIRA)" <ji...@apache.org> on 2007/04/18 17:17:15 UTC
[jira] Commented: (GERONIMO-3106) When you are in the Create
Database Pool wizard the jar driver list could show only jars containing
Driver implementations
[ https://issues.apache.org/jira/browse/GERONIMO-3106?page=com.atlassian.jira.plugin.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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (GERONIMO-3106) When you are in the Create
Database Pool wizard the jar driver list could show only jars containing
Driver implementations
Posted by Daniel Alheiros <Da...@bbc.co.uk>.
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" <da...@yahoo.com> 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" <da...@yahoo.com> 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" <am...@alumni.princeton.edu>
>>>> >> 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 <Da...@bbc.co.uk> 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)" <ji...@apache.org> 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.
Re: [jira] Commented: (GERONIMO-3106) When you are in the Create Database Pool wizard the jar driver list could show only jars containing Driver implementations
Posted by David Jencks <da...@yahoo.com>.
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" <da...@yahoo.com> 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" <am...@alumni.princeton.edu>
> >> 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 <Da...@bbc.co.uk> 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)" <ji...@apache.org> 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.
Re: [jira] Commented: (GERONIMO-3106) When you are in the Create
Database Pool wizard the jar driver list could show only jars containing
Driver implementations
Posted by Daniel Alheiros <Da...@bbc.co.uk>.
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" <da...@yahoo.com> 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" <am...@alumni.princeton.edu>
>> 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 <Da...@bbc.co.uk> 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)" <ji...@apache.org> 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.
Re: [jira] Commented: (GERONIMO-3106) When you are in the Create Database Pool wizard the jar driver list could show only jars containing Driver implementations
Posted by David Jencks <da...@yahoo.com>.
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" <am...@alumni.princeton.edu>
> 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 <Da...@bbc.co.uk> 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)" <ji...@apache.org> 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.
>
Re: [jira] Commented: (GERONIMO-3106) When you are in the Create
Database Pool wizard the jar driver list could show only jars containing
Driver implementations
Posted by Daniel Alheiros <Da...@bbc.co.uk>.
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)? 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.
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)
Regards
On 18/4/07 19:28, "Aaron Mulder" <am...@alumni.princeton.edu> 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 <Da...@bbc.co.uk> 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)" <ji...@apache.org> 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.
Re: [jira] Commented: (GERONIMO-3106) When you are in the Create Database Pool wizard the jar driver list could show only jars containing Driver implementations
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <Da...@bbc.co.uk> 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)" <ji...@apache.org> 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.
>
>
>
Re: [jira] Commented: (GERONIMO-3106) When you are in the Create
Database Pool wizard the jar driver list could show only jars containing
Driver implementations
Posted by Daniel Alheiros <Da...@bbc.co.uk>.
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)" <ji...@apache.org> 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.