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
>>>>>>
>>>>>>
>>>>
>>
>