Re: "conglomerate does not exist" error
--- Thomas Dudziak <[EMAIL PROTECTED]> wrote: > On 11/11/05, Susan Cline <[EMAIL PROTECTED]> > wrote: > > > I got this to work using the following > configuration: > > > > Tomcat 5.5.9 with these edits to the server.xml > file: snip > > This approach however ties me to Tomcat and makes it > necessary to > change the server environment neither of which I can > afford, because > my webapp is supposed to be a simple drop-in into > any servlet > container (Jetty, Tomcat, JRun, you name it). Okay, sorry about that ... didn't realize that was the case. > snip > > I created a database, derbydb using ij and created > a > > table foo in it and inserted one row. I then > imported > > it using Eclipse to the WEB-INF/classes directory. > > I think this is the crucial point. As I wrote > before, my approach > worked without problems when I ran ij on the > database before starting > the webapp (there was no need to make Tomcat aware > of the database). > However I'd like to create the database via the url > (which is done > automatically upon first connect), not via an > external tool. Okay, so I tried this. I did not use ddlutils to create the database, but what I did do was just to create the database using a stand-alone Java program. I then moved the database to the WEB-INF/classes directory like before, deployed it to Tomcat, and was able to successfully connect to it the first time I started Tomcat. So I'm not sure what is different about the way it is not working for you and it worked for me, other than some of our configuration differences. > > > As I mentioned before I haven't used Spring so I snip > You should definitely checkout Spring, makes dealing > with databases so > much easier. Specifically, you don't need to deal > with the server.xml > anymore, JDBC handling (or other ORMs like iBATIS, > OJB or Hibernate) > are nicely abstracted for you, and on top of it all > you get really > nice automatic transaction handling for which you > don't have to write > a single line of code. Sounds good, I'll give it a try. > > thanks anyway ;-) Thank you, too. > Tom >
Re: "conglomerate does not exist" error
On 11/11/05, Susan Cline <[EMAIL PROTECTED]> wrote:
> I got this to work using the following configuration:
>
> Tomcat 5.5.9 with these edits to the server.xml file:
>
>
>
>
> docBase="DerbyClasspathTest" debug="5"
> reloadable="true" crossContext="true">
>
>
>type="javax.sql.DataSource" auth="Container"
> description="Derby database"
> driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
> url="jdbc:derby:classpath:derbydb" username="APP"
> password="APP" maxActive="4" maxIdle="2"/>
>
>
>
>
>
> I placed the derby.jar file in
> $TOMCAT_HOME/common/lib.
>
> I added this entry to my web.xml:
>
>
> jdbc/derby
> javax.sql.DataSource
> Container
>
This approach however ties me to Tomcat and makes it necessary to
change the server environment neither of which I can afford, because
my webapp is supposed to be a simple drop-in into any servlet
container (Jetty, Tomcat, JRun, you name it).
> I created a simple servlet and put this in it's init
> method for a simple test:
>
> DataSource ds = null;
> Connection conn = null;
> try {
> // Obtain our environment naming context
> Context initCtx = new InitialContext();
> Context envCtx = (Context)
> initCtx.lookup("java:comp/env");
>
> // Look up our data source
> ds = (DataSource) envCtx.lookup("jdbc/derby");
> initCtx.close();
> envCtx.close();
> } catch (NamingException namingExc) {
> namingExc.printStackTrace();
> }
>
> try {
> conn = ds.getConnection();
> String query = "select * from APP.foo";
>
> Statement stmt = conn.createStatement();
> ResultSet results = stmt.executeQuery(query);
> ResultSetMetaData rsmd = results.getMetaData();
> int numberCols = rsmd.getColumnCount();
>
> while (results.next()) {
> for (int i = 1; i <= numberCols; i++) {
> System.out.println("Select *
> from APP.foo is: "
> + results.getString(i));
>
> }
> }
> results.close();
> stmt.close();
> } catch (SQLException sqlExcept) {
> sqlExcept.printStackTrace();
> }
>
> }
>
> I created a database, derbydb using ij and created a
> table foo in it and inserted one row. I then imported
> it using Eclipse to the WEB-INF/classes directory.
I think this is the crucial point. As I wrote before, my approach
worked without problems when I ran ij on the database before starting
the webapp (there was no need to make Tomcat aware of the database).
However I'd like to create the database via the url (which is done
automatically upon first connect), not via an external tool.
> As I mentioned before I haven't used Spring so I don't
> know if this is complicating anything. But I have
> verified that you can connect to the database using
> the database connection URL you wanted to, using the
> classpath identifier.
>
> (By the way, thanks! I need that for something I'm
> working on too!)
You should definitely checkout Spring, makes dealing with databases so
much easier. Specifically, you don't need to deal with the server.xml
anymore, JDBC handling (or other ORMs like iBATIS, OJB or Hibernate)
are nicely abstracted for you, and on top of it all you get really
nice automatic transaction handling for which you don't have to write
a single line of code.
thanks anyway ;-)
Tom
Re: "conglomerate does not exist" error
Hi Thomas,
I got this to work using the following configuration:
Tomcat 5.5.9 with these edits to the server.xml file:
I placed the derby.jar file in
$TOMCAT_HOME/common/lib.
I added this entry to my web.xml:
jdbc/derby
javax.sql.DataSource
Container
I created a simple servlet and put this in it's init
method for a simple test:
DataSource ds = null;
Connection conn = null;
try {
// Obtain our environment naming context
Context initCtx = new InitialContext();
Context envCtx = (Context)
initCtx.lookup("java:comp/env");
// Look up our data source
ds = (DataSource) envCtx.lookup("jdbc/derby");
initCtx.close();
envCtx.close();
} catch (NamingException namingExc) {
namingExc.printStackTrace();
}
try {
conn = ds.getConnection();
String query = "select * from APP.foo";
Statement stmt = conn.createStatement();
ResultSet results = stmt.executeQuery(query);
ResultSetMetaData rsmd = results.getMetaData();
int numberCols = rsmd.getColumnCount();
while (results.next()) {
for (int i = 1; i <= numberCols; i++) {
System.out.println("Select *
from APP.foo is: "
+ results.getString(i));
}
}
results.close();
stmt.close();
} catch (SQLException sqlExcept) {
sqlExcept.printStackTrace();
}
}
I created a database, derbydb using ij and created a
table foo in it and inserted one row. I then imported
it using Eclipse to the WEB-INF/classes directory.
I created a WAR file from Eclipse and placed the WAR
file in my Tomcat webapps directory.
Then I started Eclipse from within Tomcat and called
up the servlet. The row was returned from the db
looking at the Eclipse console.
As I mentioned before I haven't used Spring so I don't
know if this is complicating anything. But I have
verified that you can connect to the database using
the database connection URL you wanted to, using the
classpath identifier.
(By the way, thanks! I need that for something I'm
working on too!)
HTH somewhat,
Susan
--- Thomas Dudziak <[EMAIL PROTECTED]> wrote:
> On 11/11/05, Susan Cline <[EMAIL PROTECTED]>
> wrote:
>
> > I'm not sure I can help, but I'm wondering if
> there is another way to do
> > what you are trying to accomplish. It sounds like
> you can only use the
> > jdbc:derby:classpath protocol to connect to a
> database if it *is* contained
> > in a jar file.
>
> The manual specifically says that it dosn't have to
> be in a jar:
>
> "In most cases, you access databases from the file
> system as described
> above. However, it is also possible to access
> databases from the
> classpath. The databases can be archived into a jar
> or zip file or
> left as is."
>
>
(http://db.apache.org/derby/docs/10.1/devguide/cdevdvlp91854.html)
>
> > You mentioned:
> >
> > Database access is configured in Spring to use the
> DriverManagerDataSource.
> >
> > Can you send me that configuration please?
>
> This is a standard Spring DriverManagerDataSource
> configuration:
>
>
>
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
>
name="driverClassName">${jdbc.driverClassName}
>
name="url">${jdbc.runtime.url}
>
name="username">${jdbc.username}
>
name="password">${jdbc.password}
>
>
>
> with the jdbc. properties defined like this:
>
>
jdbc.driverClassName=org.apache.derby.jdbc.EmbeddedDriver
> jdbc.username=app
> jdbc.password=
> jdbc.runtime.url=jdbc:derby:classpath:derbydb
>
> > Also, from the web application can you show how
> you are connecting to the
> > database?
> > Is your first attempt to access Derby in the web
> app via a JSP or via a Java
> > class?
>
> I simply use the data source that I get from Spring,
> like with
> getConnection. Nothing fancy. Also no database
> access from a JSP
> (that's evil right ?).
> Also, database access works when ij was run on the
> database before the
> webapp accesses it.
>
> > Can you send the code for this as well?
> >
> > Also, have you tried putting the database in a jar
> file and using the
> > 'classpath' protocol to see if it does work this
> way?
>
> Nope, because that isn't really an option for me as
> I want to be able
> to change data in the database, and
> databases-in-a-jar are read-only.
> The problem is that I cannot really use a
> "directory" database url
> because then I would have to hardcode the path where
> the webapp gets
> deployed, into the configuration which of course is
> not good. And
> giving a relative path is also nto possible as I
> don't know what the
> 'current directory' is when the webapp starts - this
> depends on the
> used webserver,
Re: "conglomerate does not exist" error
On 11/11/05, Susan Cline <[EMAIL PROTECTED]> wrote:
> I'm not sure I can help, but I'm wondering if there is another way to do
> what you are trying to accomplish. It sounds like you can only use the
> jdbc:derby:classpath protocol to connect to a database if it *is* contained
> in a jar file.
The manual specifically says that it dosn't have to be in a jar:
"In most cases, you access databases from the file system as described
above. However, it is also possible to access databases from the
classpath. The databases can be archived into a jar or zip file or
left as is."
(http://db.apache.org/derby/docs/10.1/devguide/cdevdvlp91854.html)
> You mentioned:
>
> Database access is configured in Spring to use the DriverManagerDataSource.
>
> Can you send me that configuration please?
This is a standard Spring DriverManagerDataSource configuration:
${jdbc.driverClassName}
${jdbc.runtime.url}
${jdbc.username}
${jdbc.password}
with the jdbc. properties defined like this:
jdbc.driverClassName=org.apache.derby.jdbc.EmbeddedDriver
jdbc.username=app
jdbc.password=
jdbc.runtime.url=jdbc:derby:classpath:derbydb
> Also, from the web application can you show how you are connecting to the
> database?
> Is your first attempt to access Derby in the web app via a JSP or via a Java
> class?
I simply use the data source that I get from Spring, like with
getConnection. Nothing fancy. Also no database access from a JSP
(that's evil right ?).
Also, database access works when ij was run on the database before the
webapp accesses it.
> Can you send the code for this as well?
>
> Also, have you tried putting the database in a jar file and using the
> 'classpath' protocol to see if it does work this way?
Nope, because that isn't really an option for me as I want to be able
to change data in the database, and databases-in-a-jar are read-only.
The problem is that I cannot really use a "directory" database url
because then I would have to hardcode the path where the webapp gets
deployed, into the configuration which of course is not good. And
giving a relative path is also nto possible as I don't know what the
'current directory' is when the webapp starts - this depends on the
used webserver, and how the webserver was started.
Tom
Re: "conglomerate does not exist" error
Hi Tom, I'm not sure I can help, but I'm wondering if there is another way to do what you are trying to accomplish. It sounds like you can only use the jdbc:derby:classpath protocol to connect to a database if it *is* contained in a jar file. You mentioned: Database access is configured in Spring to use the DriverManagerDataSource. Can you send me that configuration please? Also, from the web application can you show how you are connecting to the database? Is your first attempt to access Derby in the web app via a JSP or via a Java class? Can you send the code for this as well? Also, have you tried putting the database in a jar file and using the 'classpath' protocol to see if it does work this way? Thanks, Susan Original Message Subject: Re: "conglomerate does not exist" errorDate: Thu, 10 Nov 2005 19:17:19 +0100From: Thomas Dudziak <[EMAIL PROTECTED]>Reply-To: Derby Discussion To: Derby Discussion On 11/10/05, Sunitha Kambhampati <[EMAIL PROTECTED]>wrote:> For using the jdbc:derby:classpath , you need to ensure that the jar> that contains your database is in your classpath. Is it possible that> when you restart the web server - that is when the 'jar that has the> database' is being picked up by the web server and derby is able to use> it ?the database is not in a jar, but rather a directory (I want to beable to write to it) which lives in WEB-INF/classes, and thus isautomatically in the classpath of the web app. And as I wrote, when ij runs/was run, I somehow can use the database.So I figured, it has something to do with the initialization of thedatabase files ?Tom
Re: "conglomerate does not exist" error
On 11/10/05, Sunitha Kambhampati <[EMAIL PROTECTED]> wrote: > For using the jdbc:derby:classpath , you need to ensure that the jar > that contains your database is in your classpath. Is it possible that > when you restart the web server - that is when the 'jar that has the > database' is being picked up by the web server and derby is able to use > it ? the database is not in a jar, but rather a directory (I want to be able to write to it) which lives in WEB-INF/classes, and thus is automatically in the classpath of the web app. And as I wrote, when ij runs/was run, I somehow can use the database. So I figured, it has something to do with the initialization of the database files ? Tom
Re: "conglomerate does not exist" error
sorry - a dot is missing in the link. correct link : http://db.apache.org/derby/docs/10.0/manuals/develop/develop38.html Sunitha Kambhampati wrote: http://dbapache.org/derby/docs/10.0/manuals/develop/develop38.html
Re: "conglomerate does not exist" error
Thomas Dudziak wrote: No, I didn't start ij from within eclipse, but rather from the commandline. And derby.home shouldn't matter when using jdbc:derby:classpath, right ? <>Even more interesting, I simply stopped the web server and restartedit without any other changes, and now access to Derby works without problems, even after additional restarts. So this has to with first-time access to the database ? For using the jdbc:derby:classpath , you need to ensure that the jar that contains your database is in your classpath. Is it possible that when you restart the web server - that is when the 'jar that has the database' is being picked up by the web server and derby is able to use it ? http://dbapache.org/derby/docs/10.0/manuals/develop/develop38.html Sunitha.
Re: "conglomerate does not exist" error
On 11/10/05, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote: > Just a wild guess: Starting ij in Eclipse sets derby.system.home to > the directory where the database is located, hence the database is > found. In the other cases derby.system.home is set to its default > value (current working directory), which is not where the database is > located. No, I didn't start ij from within eclipse, but rather from the commandline. And derby.home shouldn't matter when using jdbc:derby:classpath, right ? Tom
Re: "conglomerate does not exist" error
Thomas Dudziak <[EMAIL PROTECTED]> writes: > On 11/9/05, Mike Matrigali <[EMAIL PROTECTED]> wrote: >> In the directory where your database directory is there should >> be a file called derby.log and in it will have the part of the >> stack I am looking for. >> >> Since it works in ij - it seems like the db is good - which was the >> problem I was going to look at. It seems like there must be some set up >> issue with your web server, hopefully someone with more experience in >> that area can help out. > > Ah, yes, I found it, it landed in the eclipse root folder (I start > Tomcat from within Eclipse), but contains nothing interesting: > > > 2005-11-09 22:13:43.008 GMT: > Booting Derby version The Apache Software Foundation - Apache Derby - > 10.1.1.0 - (208786): instance c013800d-0107-7717-4a97-001ed0d0 > on database directory classpath:/derbydb > > Database Class Loader started - derby.database.classpath='' > > > Restarting the webserver without ij running, consistently generates > the "conglomerate" error. I also checked that it has nothing to do > with Eclipse, and started tomcat via the startup script, and I get the > same error. > So somehow, ij 'fixes' the Derby instance so that I can use it > afterwards, which is IMO quite strange. Just a wild guess: Starting ij in Eclipse sets derby.system.home to the directory where the database is located, hence the database is found. In the other cases derby.system.home is set to its default value (current working directory), which is not where the database is located. You can check whether this is the case by changing the connection URL from 'jdbc:derby:derbydb' to 'jdbc:derby:/full/path/to/derbydb'. -- Knut Anders
Re: "conglomerate does not exist" error
On 11/9/05, Mike Matrigali <[EMAIL PROTECTED]> wrote: > In the directory where your database directory is there should > be a file called derby.log and in it will have the part of the > stack I am looking for. > > Since it works in ij - it seems like the db is good - which was the > problem I was going to look at. It seems like there must be some set up > issue with your web server, hopefully someone with more experience in > that area can help out. Ah, yes, I found it, it landed in the eclipse root folder (I start Tomcat from within Eclipse), but contains nothing interesting: 2005-11-09 22:13:43.008 GMT: Booting Derby version The Apache Software Foundation - Apache Derby - 10.1.1.0 - (208786): instance c013800d-0107-7717-4a97-001ed0d0 on database directory classpath:/derbydb Database Class Loader started - derby.database.classpath='' Restarting the webserver without ij running, consistently generates the "conglomerate" error. I also checked that it has nothing to do with Eclipse, and started tomcat via the startup script, and I get the same error. So somehow, ij 'fixes' the Derby instance so that I can use it afterwards, which is IMO quite strange. Tom
Re: "conglomerate does not exist" error
Even more interesting, I simply stopped the web server and restarted it without any other changes, and now access to Derby works without problems, even after additional restarts. So this has to with first-time access to the database ? Tom
Re: "conglomerate does not exist" error
On 11/9/05, Mike Matrigali <[EMAIL PROTECTED]> wrote: > That stack does not include the derby internal stack, perhaps you still > have it in derby.log? I'm not entirely sure what you mean by the derby internal stack and derby.log ? I run derby in embedded mode, how can I direct it to generate such a thing (the manual structure is IMO quite confusing; a quick search did not produce anything useful about logging) ? > You can enable properties to print which query is encountering the > error. Then see if you can run the query in ij vs your webapp setup. I got the query (I'm using OJB which prints out the query in case of an error). It is: SELECT A0.id,A0.firstname,A0.lastname,A0.username,A0.password,A0.email FROM users A0 WHERE A0.username = 'tomdz'; When running with ij in WEB-INF/classes using the connection url 'jdbc:derby:derbydb', the above query works without problems. Interestingly, I re-created the database, and redeployed it and now I get a "ERROR 42X05: Table 'USERS' does not exist." error which I think, has to do with the username and schemas. For reference, I use the username 'app' to connect to Derby in both creation and in the webapp so that I don't have to deal with schemas. I'll see whether I can get the "conglomerate does not exist" error again. Tom
Re: "conglomerate does not exist" error
That stack does not include the derby internal stack, perhaps you still have it in derby.log? You can enable properties to print which query is encountering the error. Then see if you can run the query in ij vs your webapp setup. Thomas Dudziak wrote: Hi folks, I get the "The conglomerate (1.056) requested does not exist." error with Derby 10.1.1.0 and I don't understand why. Here's the setup: * I've created a database (using embedded driver) via DdlUtils into my webapp-to-be-deployed in directory WEB-INF/classes/derbydb. The database correctly contains data as I checked with ij. * I then configured my webapp (Struts + Spring) to use Derby via the url "jdbc:derby:classpath:derbydb" in the assumption that the WEB-INF/Classes folder is automatically in the classpath. * The whole stuff is packaged into a WAR and deployed into Tomcat 5.5.12 (which btw. does not know anything about the database) * The I start the webapp and try to login which in turn uses the database for the first time. This is where it goes bang. Database access is configured in Spring to use the DriverManagerDataSource, and also there is only one user (me as I'm currently developing the webapp) and only one using class in the webapp, so there is no concurrent access AFAIK (no multiple VMs or classloaders). So could perhaps somebody give me a tip what I did wrong ? regards, Tom PS: here's the stacktrace as far as Derby is concerned: Caused by: SQL Exception: The conglomerate (1.056) requested does not exist. at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.(Unknown Source) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy$TransactionAwareInvocationHandler.invoke(TransactionAwareDataSourceProxy.java:167) at $Proxy1.prepareStatement(Unknown Source)
