Matt Pouttu-Clarke <[email protected]> writes: > Bug with http sub protocol? > > Hi All, > > Trying to get Derby to open a read only database on Amazon EC2 via a > HTTP exposed S3 bucket. This is critical and a blocker because on the > cloud we avoid using local shared mount points requiring setup on > every host (i.e. We don’t use the file system directly). Using Derby > 10.8. > > According to the JavaDoc, there exists a > org.apache.derby.impl.io.URLStorageFactory, which is addressed by > using the http sub protocol. However, when I attempt to access the > following URL, Derby throws an exception: > Connection conn = > DriverManager.getConnection > ("jdbc:derby:http://localhost:8080/ipinfo";); > > Exception: > java.sql.SQLException: Database 'http://localhost:8080/ipinfo' not > found. > at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException > (SQLExceptionFactory.java:45) > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA > (SQLExceptionFactory40.java:122) > at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException > (SQLExceptionFactory40.java:71) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException > (Util.java:142) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException > (Util.java:148) > at org.apache.derby.impl.jdbc.Util.generateCsSQLException > (Util.java:227) > at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException > (EmbedConnection.java:3085) > at org.apache.derby.impl.jdbc.EmbedConnection.handleDBNotFound > (EmbedConnection.java:735) > at org.apache.derby.impl.jdbc.EmbedConnection.<init> > (EmbedConnection.java:414) > at org.apache.derby.impl.jdbc.EmbedConnection30.<init> > (EmbedConnection30.java:73) > at org.apache.derby.impl.jdbc.EmbedConnection40.<init> > (EmbedConnection40.java:51) > at org.apache.derby.jdbc.Driver40.getNewEmbedConnection > (Driver40.java:70) > at org.apache.derby.jdbc.InternalDriver.connect > (InternalDriver.java:248) > at org.apache.derby.jdbc.AutoloadedDriver.connect > (AutoloadedDriver.java:144) > at java.sql.DriverManager.getConnection(DriverManager.java:582) > at java.sql.DriverManager.getConnection(DriverManager.java:207) > at com.icrossing.collection.derbyurl.DerbyURLMain.main > (DerbyURLMain.java:18) > > When I debug the code it looks like the boot sequence cannot find the > service.properties since it looks like the URLFile:103 does not have > the “http:” in front of the URL so it throws a FileNotFoundException: > /** > * Creates an input stream from a file name. > * > * @return an input stream suitable for reading from the file. > * > * @exception FileNotFoundException if the file is not found. > */ > public InputStream getInputStream( ) throws FileNotFoundException > { > try > { > URL url = new URL( path); > return url.openStream(); > } > catch( IOException ioe){ throw new > java.io.FileNotFoundException(path);} > } // end of getInputStream > > Any ideas why Derby is stripping the HTTP for this DB URL?
I think the idea is that the http subsubprotocol specifies that what follows after it is a URL of any kind, not necessarily an HTTP URL. For example: jdbc:derby:http:file:/path/to/my/database A more generic subsubprotocol name, like url, would probably have been more intuitive. > (by the > way, it doesn’t work if I add “http:http:” either). Should I log a > Jira ticket for this, submit a patch, or what? Yes, I think you should file a JIRA. For what it's worth, it seems to work with a URL like this: jdbc:derby:https:http://localhost:8080/ipinfo (Both https and http subsubprotocol names map to URLStorageFactory and should be equivalent. I guess it's the code that strips off the subsubprotocol that is too aggressive and removes too much if the subsubprotocol and the protocol of the URL are identical.) -- Knut Anders
