I have updated the bug as per Tom's request which answers some of these
questions.
To use JavaDB based JDBC DataSource, copying the driver is not needed -
it's the DriverManager API that's problematic.
Yes, sql tag allows datasource to be specified as well.
Sahoo
On Tuesday 11 January 2011 06:14 AM, Bill Shannon wrote:
> I'm coming into this issue late so I'm just trying to understand...
>
> If I use JDBC or JPA or anything that uses a DataSource resource,
> with JavaDB, does it just work out of the box, or do I need to copy
> the driver around?
>
> That is, is this problem specific to the DriverManager API? If so,
> is there no way to make JSTL work with DataSource resources? Should
> the <sql:query> tag take the JNDI name of a DataSource resource?
>
>
> Sahoo wrote on 01/10/11 04:37 PM:
>> Yes, I have investigated, otherwise I would not have closed the bug.
>> The current
>> user is using JSTL sql tag to get a connection and our jstl
>> implementation
>> assumes it has the driver in its classpath as it uses DriverManager
>> API. Since
>> the use case is very rare, I didn't bother addressing. More over, the
>> moment
>> user uses some other driver, they have to anyway copy that driver to
>> lib/ext, so
>> fixing it only for derby does not make any sense to me. If someone
>> insists
>> fixing it, we need to revert #41690.
>>
>> Sahoo
>>
>> On Tuesday 11 January 2011 05:04 AM, Kin-man Chung wrote:
>>> No idea. You'll need to ask Sahoo, since he committed 41690.
>>>
>>> On 01/10/11 15:20, Tom Mueller wrote:
>>>> Has anyone investigated why the tests that were run to validate
>>>> revision
>>>> 41690 worked, but this application doesn't?
>>>>
>>>> Tom
>>>>
>>>> On 1/10/2011 3:38 PM, Kin-man Chung wrote:
>>>>> I agree. How do we get this on ccc committe's radar?
>>>>>
>>>>> How can this be fixed, though? Either revision 41690 needs to be
>>>>> reverted,
>>>>> or asadmin start-doman needs to do the copying of the jars. Either
>>>>> of these
>>>>> would have some performance impact, I am sure.
>>>>>
>>>>> On 01/10/11 08:32, Tom Mueller wrote:
>>>>>> Even though there is no documentation that says that it should
>>>>>> work without
>>>>>> copying the driver, this still seems to be a regression from 3.0.
>>>>>> Shouldn't
>>>>>> 15442 be marked as a regression, and the ccc committee should decide
>>>>>> whether it is ok to ship with this regression?
>>>>>>
>>>>>> If many developers are depending on this (non-documented)
>>>>>> behavior, this
>>>>>> might be a support issue.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> On 1/10/2011 10:25 AM, Doug Donahue wrote:
>>>>>>> On 1/10/11 10:36 AM, Tom Mueller wrote:
>>>>>>>> Doug,
>>>>>>>> Please open an issue for this and attach the app to the issue.
>>>>>>>> Also,
>>>>>>>> provide information about how the app is configured when it is
>>>>>>>> not working.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>> Tom
>>>>>>>
>>>>>>> I am sorry I should have update this mailing. I filed a bug it
>>>>>>> has been
>>>>>>> closed. It appears that they expect this to happen. You need to
>>>>>>> copy the
>>>>>>> the jars over to the lib directory for them to be accessible.
>>>>>>>
>>>>>>> GLASSFISH-15442: No suitable driver found for
>>>>>>> jdbc:derby://localhost:1527/derbyDB;create=true
>>>>>>> https://java.net/jira/browse/GLASSFISH-15442
>>>>>>>
>>>>>>> --Doug
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/4/2011 8:26 AM, Doug Donahue wrote:
>>>>>>>>> On 1/3/11 4:25 PM, Tom Mueller wrote:
>>>>>>>>>> Is your JSP in docroot or within a web app?
>>>>>>>>>>
>>>>>>>>>> I wonder if this is related to a performance change that we
>>>>>>>>>> made that
>>>>>>>>>> remove the derby libraries from the launcher class loader of
>>>>>>>>>> the app
>>>>>>>>>> server, and put them only in the common class loader. This
>>>>>>>>>> was done in
>>>>>>>>>> revision 41690 as part of fixing issue 13612.
>>>>>>>>>>
>>>>>>>>>> Tom
>>>>>>>>> Thanks for your reply Tom I did go and read the issue.
>>>>>>>>>
>>>>>>>>> The JSP pages are in the app. This could be a configuration
>>>>>>>>> issue on my
>>>>>>>>> end, I fully understand that if this was any other database
>>>>>>>>> that I would
>>>>>>>>> need to load the drivers in the lib directory. The only reason
>>>>>>>>> I did not
>>>>>>>>> want to just do that in this case is that we bundle this
>>>>>>>>> database with
>>>>>>>>> glassfish and I thought it should work out of the box with out
>>>>>>>>> having to
>>>>>>>>> move jarfiles around.
>>>>>>>>>
>>>>>>>>> Any thoughts?
>>>>>>>>> Doug
>>>>>>>>>>
>>>>>>>>>> On 1/3/2011 2:45 PM, Doug Donahue wrote:
>>>>>>>>>>> When using a the <sql:query> JSTL tag in a JSP page I am
>>>>>>>>>>> seeing the
>>>>>>>>>>> following failure.
>>>>>>>>>>>
>>>>>>>>>>> Could not execute the query SELECT * FROM jstl_tab1
>>>>>>>>>>> when using
>>>>>>>>>>> jdbc:derby://localhost:1527/derbyDB;create=true,org.apache.derby.jdbc.ClientDriver,cts1,cts1
>>>>>>>>>>>
>>>>>>>>>>> for the dataSource attribute! The Exception that was raised
>>>>>>>>>>> is:javax.servlet.jsp.JspException: Unable to get connection,
>>>>>>>>>>> DataSource invalid: java.sql.SQLException: No suitable
>>>>>>>>>>> driver found for
>>>>>>>>>>> jdbc:derby://localhost:1527/derbyDB;create=true
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Now if I copy /glassfish3/javadb/lib/derbyclient.jar to
>>>>>>>>>>> /glassfish3/glassfish/lib/endorsed/ and run the webapp, the
>>>>>>>>>>> driver is
>>>>>>>>>>> found with no issues at all.
>>>>>>>>>>>
>>>>>>>>>>> Should I have to copy this jarfile into the endorsed dir?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Doug
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Oracle <http://www.oracle.com>
>>>>>>>>>>> Doug Donahue| Principal Member of Technical Staff |
>>>>>>>>>>> +1.781.442.2089
>>>>>>>>>>> Oracle Java Engineering
>>>>>>>>>>> 35 Network Drive
>>>>>>>>>>> Burlington, MA 01803
>>>>>>>>>>> Douglas.Donahue_at_oracle.com
>>>>>>>>>>>
>>>>>>>>>>> Green Oracle <http://www.oracle.com/commitment> Oracle
>>>>>>>>>>> is committed
>>>>>>>>>>> to developing practices and products that help protect the
>>>>>>>>>>> environment
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Oracle <http://www.oracle.com>
>>>>>>>>> Doug Donahue| Principal Member of Technical Staff |
>>>>>>>>> +1.781.442.2089
>>>>>>>>> Oracle Java Engineering
>>>>>>>>> 35 Network Drive
>>>>>>>>> Burlington, MA 01803
>>>>>>>>> Douglas.Donahue_at_oracle.com
>>>>>>>>>
>>>>>>>>> Green Oracle <http://www.oracle.com/commitment> Oracle is
>>>>>>>>> committed to
>>>>>>>>> developing practices and products that help protect the
>>>>>>>>> environment
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Oracle <http://www.oracle.com>
>>>>>>> Doug Donahue| Principal Member of Technical Staff | +1.781.442.2089
>>>>>>> Oracle Java Engineering
>>>>>>> 35 Network Drive
>>>>>>> Burlington, MA 01803
>>>>>>> Douglas.Donahue_at_oracle.com
>>>>>>>
>>>>>>> Green Oracle <http://www.oracle.com/commitment> Oracle is
>>>>>>> committed to
>>>>>>> developing practices and products that help protect the environment
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>