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:
[EMAIL PROTECTED] 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.
