You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Harald Wehr <hw...@hs-harz.de> on 2003/12/15 07:58:12 UTC
ClassCastException for Postgres datasource in Generator
I posted this to cocoon user list but did not get a helpful answer, so I
try again here. Sorry for double posting:
In one of our Generators we want to use Postgres as Datasource. In
web.xml we added the postgres driver this way:
<init-param>
<param-name>load-class</param-name>
<param-value>
org.postgresql.Driver
</param-value>
</init-param>
In cocoon.xconf we added the parameters for the connection:
<datasources>
<jdbc name="vrgis">
<pool-controller max="10" min="5"/>
<dburl>jdbc:postgresql://192.168.9.2/vrgis</dburl>
<user>vrgis</user>
<password>sigrv</password>
</jdbc>
</datasources>
In our Generator we implemented the Interface Composable with this method:
public void compose(ComponentManager manager) throws ComponentException {
ComponentSelector selector = (ComponentSelector)
manager.lookup(DataSourceComponent.ROLE+"Selector");
this.datasource = (DataSourceComponent) selector.select("vrgis");
}
Wenn we try to use the datasource in the generate-method we get a
ClassCastException.
--schnipp
Connection conn = datasource.getConnection();
System.out.println(conn);
((Jdbc3Connection)conn).addDataType("geometry","org.postgis.PGgeometry");
((Jdbc3Connection)conn).addDataType("MultiLineString","org.postgis.MultiLineString");
--schnipp
The exception occurs when we try to cast the Connection. When we build
the connection ourself everything is working fine:
Class.forName("org.postgresql.Driver");
String url = "jdbc:postgresql://192.168.9.2/vrgis";
Connection conn = DriverManager.getConnection(url, dbuser, dbpass);
((Jdbc3Connection)conn).addDataType("geometry","org.postgis.PGgeometry");
((Jdbc3Connection)conn).addDataType("MultiLineString","org.postgis.MultiLineString");
System.out.println(conn);
In both ways the System.outs give:
org.postgresql.jdbc3.Jdbc3Connection
Do you have any hints, whats happening here? We are using Cocoon 2.1.3
on Suse Linux 8.1. We tested several postgres-driver version, but that
didn't help out here.
Harald
Re: ClassCastException for Postgres datasource in Generator
Posted by Harald Wehr <hw...@hs-harz.de>.
Geoff Howard wrote:
> Harald Wehr wrote:
>
>> Thanks for your fast answer. I tested your hints but that didn't help.
>> Nevertheless there is an interesting debug output. If I call
>> conn.getClass().getName() to the connection I get from the pool, the
>> output is:
>> ------------
>> $Proxy4
>> ------------
>
>
> Looks to me like Excalibur is wrapping the class in a dynamic proxy
> which is then leading to the class cast exception. Unfortunately, I
> don't know whether you're supposed to find an abstracted api within
> excalibur datasource for the feature you want (which seemed to be
> hinted at by Bertrand's answer, or if "fixing" the proxy is what is
> needed, or if this is just a good old fashioned bug or unimplemented
> feature.
>
> I seem to recall that excalibur was using the dynamic proxies in order
> to get around JDK 1.3/1.4 differences in jdbc. So, my guess is you are
> using JDK 1.3? If so, perhaps switching to 1.4 would make the proxy
> unnecessary and would be a workaround.
I'm already working with JDK 1.4.2, so this can't be an issue here.
>
> BTW, what does the stack trace say besides ClassCastException?
Here is the full stack trace:
java.lang.ClassCastException
at
de.hsharz.vrgis.cocoon.SVGGenerator.getVector(SVGGenerator.java:68)
at
de.hsharz.vrgis.cocoon.SVGGenerator.convert(SVGGenerator.java:135)
at
de.hsharz.vrgis.cocoon.SVGGenerator.generate(SVGGenerator.java:336)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:549)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:196)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:501)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:147)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:163)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:152)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:354)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307)
at org.apache.cocoon.Cocoon.process(Cocoon.java:656)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1112)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:356)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1723)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:514)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1673)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:783)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:945)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:800)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:454)
Harald
Re: ClassCastException for Postgres datasource in Generator
Posted by Geoff Howard <co...@leverageweb.com>.
Harald Wehr wrote:
> Thanks for your fast answer. I tested your hints but that didn't help.
> Nevertheless there is an interesting debug output. If I call
> conn.getClass().getName() to the connection I get from the pool, the
> output is:
> ------------
> $Proxy4
> ------------
Looks to me like Excalibur is wrapping the class in a dynamic proxy
which is then leading to the class cast exception. Unfortunately, I
don't know whether you're supposed to find an abstracted api within
excalibur datasource for the feature you want (which seemed to be
hinted at by Bertrand's answer, or if "fixing" the proxy is what is
needed, or if this is just a good old fashioned bug or unimplemented
feature.
I seem to recall that excalibur was using the dynamic proxies in order
to get around JDK 1.3/1.4 differences in jdbc. So, my guess is you are
using JDK 1.3? If so, perhaps switching to 1.4 would make the proxy
unnecessary and would be a workaround.
BTW, what does the stack trace say besides ClassCastException?
> while the connection from the manual building gives:
> ------------
> org.postgresql.jdbc3.Jdbc3Connection
> ------------
>
> Do you have any hints on that?
Geoff
Re: ClassCastException for Postgres datasource in Generator
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Hi Harald:
I think the problem is a little OT, but please check this:
http://archives.postgresql.org/pgsql-jdbc/2003-04/msg00063.php
Best Regards,
Antonio Gallardo
Re: ClassCastException for Postgres datasource in Generator
Posted by Harald Wehr <hw...@hs-harz.de>.
Antonio,
>
> It is normal. Every conection has a name in this case it is $Proxy4. I
> saw similars names using OJB.
>
> Are you ever tried to connect to the Database using JDBC from another tool
> using the same driver? For example:
>
> Squirrel SQL - http://squirrel-sql.sourceforge.net/
No I never did it. I just downloaded squirrel and will give it a try in
next days. I will inform you about the results.
>
> Sometimes the problem can be in the username - password. Also check if
> postgres allow tcp connections.
This is working right. Postgres allows tcp connections as we can connect
with a connection we make ourself. The exception only happens if we do
the cast, as we need to add some special datatypes (details in my first
mail)
>
> Please note I am just guessing where the things can be wrong. :-D
Thanks for your help.
Harald
Re: ClassCastException for Postgres datasource in Generator
Posted by Harald Wehr <hw...@hs-harz.de>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>
>>So, to answer Harald's question, he should use Serviceable instead of
>>Composable, and may be file a bug against avalon excalibur component
>>manager (Carsten? any info on this?)
>>
>
> Afaik, this is not considered a bug :) Cocoon is based on the ECM which
> is a ComponentManager. But you can use Serviceable and in that case
> still the ComponentManager is used which requires the Component interface.
>
So i changed my Generator to not implement the Composable but the
Serviceable interface. But that didn't work either. Here is my
service-method:
public void service(ServiceManager manager) throws ServiceException {
System.out.println("in Service");
serviceSelector selector =
(ServiceSelector) manager.lookup(
DataSourceComponent.ROLE + "Selector");
this.datasource = (DataSourceComponent) selector.select("vrgis");
}
Is this method right or do I have to implement something else here?
Harald
Re: ClassCastException for Postgres datasource in Generator
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Thanks Vadim! You are right. I mixed it with constrains returned in
PostgreSQL driver:
$2
Best Regards,
Antonio Gallardo
Vadim Gritsenko dijo:
> Antonio Gallardo wrote:
>
>>Harald Wehr dijo:
>>
>>
>>>Thanks for your fast answer. I tested your hints but that didn't help.
>>>Nevertheless there is an interesting debug output. If I call
>>>conn.getClass().getName() to the connection I get from the pool, the
>>>output is:
>>>------------
>>>$Proxy4
>>>------------
>>>
>>>while the connection from the manual building gives:
>>>------------
>>>org.postgresql.jdbc3.Jdbc3Connection
>>>------------
>>>
>>>Do you have any hints on that?
>>>
>>>
>>
>>It is normal. Every conection has a name in this case it is $Proxy4.
>>
>
> Antonio,
>
> From the context of Bertrand's email, "$Proxy4" is output of
> getClass().getName(), so it never can be a connection name, it is
> *class* name. Classnames such is these are given to the proxies, which
> are dynamically generated by the excalibur.
>
> Now, I don't know why ClassCastException is happening, but I seen those,
> and usually it can be fixed by either extending component class from
> Component, or by using ServiceManager.
>
> So, to answer Harald's question, he should use Serviceable instead of
> Composable, and may be file a bug against avalon excalibur component
> manager (Carsten? any info on this?)
>
> Vadim
>
>
>
RE: ClassCastException for Postgres datasource in Generator
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Geoff Howard wrote:
> It's the excalibur datasource that's in question here, not his code.
> He's not getting a proxy returned on his component but on the Datasource
> he's gotten out of the DataSourceSelector. IIRC Component/Serviceable
> is not the only time you'll get a proxy out of excalibur-xxxx. Does
> anyone know about the JDK 1.3/1.4 thing it does?
>
Ah, ok, I didn't follow the thread and just saw my name in there :)
Sorry
Carsten
Re: ClassCastException for Postgres datasource in Generator
Posted by Geoff Howard <co...@leverageweb.com>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>
>>So, to answer Harald's question, he should use Serviceable instead of
>>Composable, and may be file a bug against avalon excalibur component
>>manager (Carsten? any info on this?)
>>
>
> Afaik, this is not considered a bug :) Cocoon is based on the ECM which
> is a ComponentManager. But you can use Serviceable and in that case
> still the ComponentManager is used which requires the Component interface.
It's the excalibur datasource that's in question here, not his code.
He's not getting a proxy returned on his component but on the Datasource
he's gotten out of the DataSourceSelector. IIRC Component/Serviceable
is not the only time you'll get a proxy out of excalibur-xxxx. Does
anyone know about the JDK 1.3/1.4 thing it does?
Geoff
RE: ClassCastException for Postgres datasource in Generator
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
> So, to answer Harald's question, he should use Serviceable instead of
> Composable, and may be file a bug against avalon excalibur component
> manager (Carsten? any info on this?)
>
Afaik, this is not considered a bug :) Cocoon is based on the ECM which
is a ComponentManager. But you can use Serviceable and in that case
still the ComponentManager is used which requires the Component interface.
Carsten
Re: ClassCastException for Postgres datasource in Generator
Posted by Vadim Gritsenko <va...@verizon.net>.
Antonio Gallardo wrote:
>Harald Wehr dijo:
>
>
>>Thanks for your fast answer. I tested your hints but that didn't help.
>>Nevertheless there is an interesting debug output. If I call
>>conn.getClass().getName() to the connection I get from the pool, the
>>output is:
>>------------
>>$Proxy4
>>------------
>>
>>while the connection from the manual building gives:
>>------------
>>org.postgresql.jdbc3.Jdbc3Connection
>>------------
>>
>>Do you have any hints on that?
>>
>>
>
>It is normal. Every conection has a name in this case it is $Proxy4.
>
Antonio,
From the context of Bertrand's email, "$Proxy4" is output of
getClass().getName(), so it never can be a connection name, it is
*class* name. Classnames such is these are given to the proxies, which
are dynamically generated by the excalibur.
Now, I don't know why ClassCastException is happening, but I seen those,
and usually it can be fixed by either extending component class from
Component, or by using ServiceManager.
So, to answer Harald's question, he should use Serviceable instead of
Composable, and may be file a bug against avalon excalibur component
manager (Carsten? any info on this?)
Vadim
Re: ClassCastException for Postgres datasource in Generator
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Harald Wehr dijo:
> Thanks for your fast answer. I tested your hints but that didn't help.
> Nevertheless there is an interesting debug output. If I call
> conn.getClass().getName() to the connection I get from the pool, the
> output is:
> ------------
> $Proxy4
> ------------
>
> while the connection from the manual building gives:
> ------------
> org.postgresql.jdbc3.Jdbc3Connection
> ------------
>
> Do you have any hints on that?
It is normal. Every conection has a name in this case it is $Proxy4. I
saw similars names using OJB.
Are you ever tried to connect to the Database using JDBC from another tool
using the same driver? For example:
Squirrel SQL - http://squirrel-sql.sourceforge.net/
Sometimes the problem can be in the username - password. Also check if
postgres allow tcp connections.
Please note I am just guessing where the things can be wrong. :-D
Best Regards,
Antonio Gallardo
Re: ClassCastException for Postgres datasource in Generator
Posted by Harald Wehr <hw...@hs-harz.de>.
Thanks for your fast answer. I tested your hints but that didn't help.
Nevertheless there is an interesting debug output. If I call
conn.getClass().getName() to the connection I get from the pool, the
output is:
------------
$Proxy4
------------
while the connection from the manual building gives:
------------
org.postgresql.jdbc3.Jdbc3Connection
------------
Do you have any hints on that?
Harald
Re: ClassCastException for Postgres datasource in Generator
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 15 déc 2003, à 07:58 Europe/Zurich, Harald Wehr a écrit :
> ...In cocoon.xconf we added the parameters for the connection:
> <datasources>
> <jdbc name="vrgis">
> <pool-controller max="10" min="5"/>
> <dburl>jdbc:postgresql://192.168.9.2/vrgis</dburl>
> <user>vrgis</user>
> <password>sigrv</password>
> </jdbc>
> </datasources>
I'm not sure if this applies to your case, but
http://avalon.apache.org/excalibur/api/org/apache/avalon/excalibur/
datasource/JdbcDataSource.html
says that you need a connection-class attribute to use JDBC3 features.
> Connection conn = datasource.getConnection();
For debugging, you could check what you got first:
Object obj = datasource.getConnection();
debug(obj.getClass().getName());
HTH
-Bertrand