db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: ClassCastException in CountAggregator
Date Sat, 17 Dec 2005 01:43:07 GMT
Edson Carlos Ericksson Richter wrote:

> In NetBeans environment, you could define your Resources under 
> server.xml (bad option) under META-INF/context.xml file (better, 
> project based - allow several projects in one installation without 
> interference between projects). So I put it in META-INF/context.xml.
>
>
> Thanks for your attention,
>
> Edson Richter
>
>
> Stanley Bradbury escreveu:
>
>> Edson Carlos Ericksson Richter wrote:
>>
>>> As stated in my previous mail, the connection pool is declared
>>> <Resource auth="Container" description="Biblio" name="jdbc/Biblio"
>>> type="javax.sql.DataSource" username="" password=""
>>> driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
>>> url="jdbc:derby:c:/projects/biblio/database;" maxActive="10" 
>>> maxIdle="2"/>
>>>
>>>
>>> And in web.xml I just have a resource-ref, as required by specs:
>>>
>>>  <resource-ref>
>>>    <description></description>
>>>    <res-ref-name>jdbc/Biblio</res-ref-name>
>>>    <res-type>javax.sql.DataSource</res-type>
>>>    <res-auth>Container</res-auth>
>>>  </resource-ref>
>>>
>>>
>>> The code running is (it's a generic code I use to test queries, so 
>>> don't be afraid about weird coding):
>>>
>>>        <sql:query var="result" dataSource="jdbc/Biblio">
>>>          select count(*) from my_table
>>>        </sql:query>
>>>        <table border='1' cellspacing='0' cellpadding='2'>
>>>          <tr>
>>>        <c:forEach items="${result.columnNames}" var="col">
>>>          <th>${col}</th>
>>>        </c:forEach>
>>>          </tr>
>>>        <c:forEach items="${result.rows}" var="row">
>>>          <tr>
>>>            <c:forEach items="${result.columnNames}" var="col">
>>>              <td>${mgr:stripClob(row[col])}</td>
>>>            </c:forEach>
>>>          </tr>
>>>        </c:forEach>
>>>        </table>
>>>
>>>
>>> The error occur at <sql:query...>, so rest of code is just here to 
>>> illustrate usage.
>>>
>>> At last, the derby.jar and derbypt_BR.jar are in 
>>> $NETBEANS_HOME/enterprise2/jakarta-tomcat-5.5.9/commons/lib/, so 
>>> classes are avaliable to the pool. If I remove them, I get problems 
>>> with connection (and plain queries stop working).
>>>
>>>
>>> I expect this helps... I will not have much time free help, but from 
>>> times to times I'll check to see if there is anything I could 
>>> contribute.
>>>
>>> Best regards,
>>>
>>> Edson Richter
>>>
>>>
>>>
>>> Stanley Bradbury escreveu:
>>>
>>>> edson.richter@mgrinformatica.com.br wrote:
>>>>
>>>>> Thank you all for the tips.
>>>>>
>>>>> Before giving up using derby, I have: 1) checked for older 
>>>>> versions. No, there are none (in
>>>>> real, I tried a fresh install of Tomcat). I double checked 
>>>>> $JAVA_HOME/jre/lib/ext, and
>>>>> tryied including install a new version of JDK (I was using 
>>>>> 1.5.0_04 and made a try with
>>>>> 1.5.0_06 - no differences).
>>>>> I tryied a simple JSP that take a connection from the pool and 
>>>>> executed a simple select
>>>>> count(*) from some_table and error is the same.
>>>>>
>>>>> Interesting is that I tryied Ij, and the error didn't occured.
>>>>> But, Ij is not using pt_BR messages, and I suspect error is 
>>>>> related (but then I give up: I
>>>>> could not spent more than a couple of hours without sucess 
>>>>> searching on the net - I searched
>>>>> Google, MSN, Altavista). db.apache.org was unavaliable yesterday, 
>>>>> and I could not search
>>>>> mailing lists.
>>>>>
>>>>> So, without web support (even from the list), I could not defend 
>>>>> Derby anymore in the
>>>>> project, and manager directed all development to a comercial 
>>>>> database, unfortunatelly.
>>>>>
>>>>> At all, thank you... But don't forget to check what could be wrong 
>>>>> - there is a serious
>>>>> erro/bugr in there.
>>>>>
>>>>> Details:
>>>>>
>>>>> - Tomcat 5.5.9 embedded in NetBeans 5.0 Beta 2
>>>>> - Tomcat 5.5.7 embedded in NetBeans 4.1
>>>>> - Connection obtained with 
>>>>> 'jdbc:derby:c:/projects/biblio/database' (it's embedded) - Plain
>>>>> queries works fine (select * from some_table)
>>>>> - Aggregate count throw ClassCastException (select count(*) from 
>>>>> some_table)
>>>>>
>>>>> Connection declaration:
>>>>>
>>>>> <Resource auth="Container" description="Biblio" name="jdbc/Biblio"
>>>>> type="javax.sql.DataSource" username="" password=""
>>>>> driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
>>>>> url="jdbc:derby:c:/projects/biblio/database;" maxActive="10" 
>>>>> maxIdle="2"/>
>>>>>
>>>>> Here is stack trace:
>>>>>
>>>>> 08/12/2005 16:29:24 org.apache.catalina.core.ApplicationDispatcher 
>>>>> invoke
>>>>> SEVERE: Servlet.service() for servlet jsp threw exception
>>>>> ERROR 38000: A exceção 'java.lang.ClassCastException:
>>>>> org.apache.derby.impl.sql.execute.CountAggregator' foi emitida ao 
>>>>> avaliar uma expressão.
>>>>>        at 
>>>>> org.apache.derby.iapi.error.StandardException.newException(Unknown 
>>>>> Source)
>>>>>        at 
>>>>> org.apache.derby.iapi.error.StandardException.unexpectedUserException(Unknown

>>>>>
>>>>> Source)
>>>>>        at 
>>>>> org.apache.derby.impl.sql.execute.GenericAggregator.getAggregatorInstance(Unknown

>>>>>
>>>>> Source)
>>>>>        at 
>>>>> org.apache.derby.impl.sql.execute.GenericAggregator.initialize(Unknown

>>>>> Source)
>>>>>  
>>>>>
>>>> ......  SNIP ...
>>>>
>>>> Hi Edson -
>>>>
>>>> Could you help me setup a test case for this problem?  It would be 
>>>> great if  you could provide a test case for the problem and file a 
>>>> JIRA entry with the test case attached (please let me know if you 
>>>> can do this).  It sounds, however, that you are working to a tight 
>>>> timeframe so I am willing to attempt to create a test case but need 
>>>> some additional information.
>>>> I have not used NetBeans but know a bit about JSPs with Tomcat.  
>>>> Could you post the information I will need to perform the test you 
>>>> describe as:
>>>>
>>>> ".. I tryied a simple JSP that take a connection from the pool and 
>>>> executed a simple select count(*) from some_table and error is the 
>>>> same .."
>>>>
>>>> Here are the things I can think of that will be very helpful: + 
>>>> Having the JSP code would be very helpful - would you post it?
>>>> +  I need to know how the connection pool was defined (what entries 
>>>> were placed in server.xml, the application deployment XML file and 
>>>> the web.xml file). +  If there any other settings needed to setup 
>>>> the connection pool in the Tomcat/NetBeans environment please 
>>>> include those also.
>>>> I have located another report of this stack trace when performing 
>>>> 'select count(*)' in a different server that did not seem to relate 
>>>> to codesets so I am hoping that  pt_BR is not required to debug 
>>>> this problem.
>>>>
>>>> Thanks in advance
>>>>
>>>>
>>>>
>>>
>> Hi Edson -
>>
>> Thanks for the reply - I certainly understand being busy and 
>> appreciate your time to respond to my questions.  My newbie-academic 
>> understanding of Tomcat is that the pool can be defined in a couple 
>> of places but most commonly is declared in the server.xml file.  
>> Within server.xml it can be declared as a <CONTEXT> element inside 
>> the <HOST> element or in the GlobalNaming space within the <Server> 
>> element.  I have always worked with datasources defined in the 
>> Global-Server space and will setup my test in that manner.  Please 
>> let me know if this not how your system is configured and I will 
>> adjust my testing..
>>
>>
>>
>
Hi Edson -
I failed to get to testing my theory today and will not be able to get 
back to the test until after the holidays  : (
I wanted to pass this information on to you in case you might find it 
helpful in the meantime.
 I believe you will not have this problem if you define the datasource 
in the GlobalNamingResources section of server.xml then create a 
ResourceLink to it in the application context.  This is how JPetStore is 
configured with Derby and TomCat in the paper at:   
http://db.apache.org/derby/integrate/DerbyTomcat5512JPetStor.html.  The 
embedded driver is very sensative to where it is loaded in a classloader 
hierarchy.

I plan to test this and investigate the classloader theory.  I believe 
that the datasource you define in META-INF/context.xml is being loaded 
by the application classloader.  This is not a problem for a standard 
JDBC driver that connects to a database server but when you use the 
Cloudscape embedded driver things are quite different.  The embedded 
driver is the database engine (for all intents and purposes).  When the 
driver is loaded at the application level the DBMS (not just the driver) 
is running in the Webapp classloader and cannot see key classes higher 
in the heiarchy (i.e. DBCP and possibly other derby classes loaded in 
the COMMON classloader).  I do not know if Tomcat will do this but I 
have seen where Derby classes are spread across classloaders in a JVM 
and give the same exception you are seeing.

Hope this helps.


Mime
View raw message