cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frank Rennekamp <frank.rennek...@tanto.de>
Subject Is it a bug in the cron block?
Date Thu, 24 Feb 2005 08:12:17 GMT
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.

Frank Rennekamp


Mime
View raw message