cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: Is it a bug in the cron block?
Date Thu, 24 Feb 2005 08:25:19 GMT
Frank Rennekamp wrote:
> Hi,
> 
> I tried to use the cron block and found some difficulties. Before I
> forget it, I'm working with cocoon 2.1.6, java SDK 1.4.2, tomcat 5.0.28
> and linux (debian).
> 
> Activating the cron block with standard values in the cocoon.xconf
> worked fine. 
> But I wanted to save the cron jobs in a database, so I made one change
> in the configuration and was using the JobStore 'tx':
> 
>       <store type="tx"
> delegate="org.quartz.impl.jdbcjobstore.HSQLDBDelegate">
>         <datasource provider="jndi">jdbc/personnel</datasource>
>       </store>
> 
> (By the way, the only documentation found here was:'tx' and 'cmt' stores
> require datasource configuration. Attributes delegate and provider are
> optional. Not very helpfull, and which database structure do I have to
> use? In the end I found this information on the quatz-scheduler
> homepage, but it would be nice to bundle this with the cron block)
> 
> 
> First I hoped I could use the datasource defined in the cocoon.xconf,
> but I didn't find a solution.
> So I had to configure the same datasource again, this time for use as
> JNDI Datasource.
> 
> I was modifying the server.xml and the cocoon/WEB-INF/web.xml, but I
> always got the same error:
> 
> org.quartz.SchedulerConfigException: Failure occured during job
> recovery. [See nested exception: org.quartz.JobPersistenceException:
> Failed to obtain DB connection from data source 'jndi:jdbc/personnel':
> java.sql.SQLException: Could not retrieve datasource via JNDI url
> 'jdbc/personnel' javax.naming.NameNotFoundException: Name jdbc is not
> bound in this Context [See nested exception: java.sql.SQLException:
> Could not retrieve datasource via JNDI url 'jdbc/personnel'
> javax.naming.NameNotFoundException: Name jdbc is not bound in this
> Context]]
> 
> 
> Then I got the sourcecode of the quartz scheduler and found where I was
> running into problems:
> 
> src/java/main/org/quartz/utils/JNDIConnectionProvider.java
> 
> the function init():
> 
>     private void init() {
> 
>         if (!isAlwaysLookup()) {
>             try {
>                 Context ctx = null;
>                 if (props != null) ctx = new InitialContext(props);
>                 else
>                     ctx = new InitialContext();
> 
>                 datasource = (DataSource) ctx.lookup(url);
>             } catch (Exception e) {
>                 getLog().error(
>                         "Error looking up datasource: " +
> e.getMessage(), e);
>             }
>         }
>     }
> 
> 
> 
> Changing it into:
> 
>     private void init() {
> 
>         if (!isAlwaysLookup()) {
>             try {
>                 Context ctx = null;
>                 if (props != null) ctx = new InitialContext(props);
>                 else
>                     ctx = new InitialContext();
> 
>                 Context envCtx = (Context) ctx.lookup("java:comp/env");
>                 datasource = (DataSource) envCtx.lookup(url);
>             } catch (Exception e) {
>                 getLog().error(
>                         "Error looking up datasource: " +
> e.getMessage(), e);
>             }
>         }
>     }
> 
> 
> and compiling and replacing it with the quartz jar in the cocoon package
> seems to solve the problem.
> 
> I don't know enough about JNDI to tell if this is a bug or if this is
> just a house made problem. Can anyone tell me?
> 
> By the way, using the hsqldb database which is included in cocoon with
> this aproach it's not possible, I got always a JNDI/SQL Error because
> the database wasn't up, and because of this (early) error, the database
> wasn't coming up. I had to use a standalone database.
> 
> And when I'm right here, the commentar to the standard values must be
> fixed, too, some are wrong, e.g.:
> 
>         <!--+
>             | How big should the queue be.
>             | Defaults to unlimited size (<0 == default)
>             +-->
>         <queue-size>-1</queue-size>
> 
>         <!--+
>             | The maximum size of the pool.
>             | Defaults to Integer.MAX_VALUE (<0 == default)
>             +-->
>         <max-pool-size>-1</max-pool-size>
> 
> At least one of them isn't working with a value of 0.
Please create a patch and post it into bugzilla so your work does not 
get lost.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
Project Manager                                    MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message