You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Tony Giaccone <tg...@masslight.net> on 2010/06/11 22:14:49 UTC
Swapping Postgres for Derby
I asked for a bit of assistance to help me swap out the Derby persistence manager in Sling for a
Database backed system.
I was advised to look at the OSGi bundles for JDBC drivers and to get a better understanding of how
that driver the Felix OSGi container is used by Sling..
What follows is the process I used, and how I managed to be successful. I hope that anyone else who
needs to follow this path will find this helpful and give you the specific advice you need to make this
swap out.
Mind you there are some problems with this path. The main one being that none of the maven testing
works. It looks like this happens because the Derby DB is initialized to blank each time it spins up
while Postgress keeps state. I really haven't looked in detail at why this is, that is just my supposition.
However, I was able to successfully deploy sling into glass fish and create nodes which are backed
by data in the database. For now, that's good enough for me.
My intent in this was to do the minimum necessary to get this to work. As a result I have not tried to
remove any of the existing structure that supported using Derby. I that effort was only going to make
the process that more difficult. And made it that much more unlikely to succeed for someone who
knows as little as I do. What I did was augment the build process to include the artifacts necessary to
use the DatabasePersistance manager and Postgres. Once I have this working on my local build,
I'll look into what it takes to do the same, and I expect that will be easy, for Oracle.
There is an assumption here that you have a copy of postgres running on your local machine, and that
it's on the standard postgres port and that you have a schema set up for Sling/Jackrabbit to use and an
Postgress userid with access to that database.
Typical warnings apply, I know very little about Sling or Jackrabbit, I'm about as novice as you can be
with both of these, as a result your milage may vary. I've done no testing on this, the only reason I know
it works is that jackrabbit created the tables in the DB Schema. With all that said here's the process
that seems to be working for me. The sling files I've modified are in bold.
The first change I made was to go to a pom file:
sling/bundles/jcr/jackrabbit-server/pom.xml
This file is integral to how the derby code gets loaded. So I just duplicated the line but changed it to
the driver for postgresql.
org.apache.derby.jdbc;resolution:=optional,
org.postgresql.Driver;resolution:=optional,
Once this was done the next step was to ensure that the postgres drivers got loaded. To get them
loaded they must be part of an OSGi bundle. My first attempts to get this working relied on bundles that
had been suggested to me from springsource.com
http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.postgresql.jdbc3&version=8.3.603&searchType=bundlesByName&searchQuery=postgres
I was NOT able to get those drivers/bundles working. I don't think the Manifest files contained in those
jar files are correct. I burned the better part of two days (I was totally ignorant, and still am mostly
ignorant about OSGi). That ignorance only made the process more complicated.
This pdf helped immensely.
http://jonas.ow2.org/JONAS_5_2_0_M1/doc/doc-en/pdf/howto_install_jdbc_driver.pdf
To get bundles that would work, I did the following. I downloaded the postgres jdbc drivers. I also
downloaded the bnd tool (http://www.aqute.biz/Code/Bnd)
I used the bnd tool to wrap both sets of drivers.
$ bnd wrap postgresql-8.4-701.jdbc3.jar
$ mv postgresql-8.4-701.jdbc3.bar postgresql-8.4-701.jdbc3-bnd.jar
$ bnd wrap postgresql-8.4-701.jdbc4.jar
$ mv postgresql-8.4-701.jdbc4.bar postgresql-8.4-701.jdbc4-bnd.jar
In this way I had both level 3 and level 4 drivers available. I wasn't sure which ones I was going to
need. I then inserted them into my local maven repository.
$ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc4 \
-Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc4-bnd.jar
$ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc3 \
-Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc3-bnd.jar
Now the bundles where in my repository, and ready to be used. They have unique names I
appended -bnd to the file names so that they are obviously different. From the jar files.
To get the jdbc jar files into the right place in launchpad, I had to add the bundle to the build so that
they would be included.
I did this by modifying this file:
sling/launchpad/builder/src/main/bundles/list.xml
Look for this line:
<startLevel level="15">
add this bundle:
<bundle>
<groupId>postgresql</groupId>
<artifactId>postgresql</artifactId>
<version>8.4.701.jdbc4</version>
</bundle>
Make the following change:
in this file:
sling/bundles/jcr/jackrabbit-server/src/main/resources/repository.xml
change this stanza of XML (it occurs twice in this file):
<PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
<param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
<param name="schemaObjectPrefix" value="${wsp.name}_"/>
<param name="shutdownOnClose" value="true"/>
</PersistenceManager>
To this:
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
<param name="driver" value="org.postgresql.Driver"/>
<param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
<param name="schema" value="postgresql"/>
<param name="user" value="YourUser"/>
<param name="password" value="YourUserPWD"/>
<param name="schemaObjectPrefix" value="public"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
In this stanza of XML make the following substitutions for your DB
YourDBSchema is the name of your Postgres Database Schema
YourUser is the userid of a valid Postgres User
YourUserPwd is the password for that User.
You'll need to change one last file:
bundles/commons/testing/src/main/resources/jackrabbit-test-config.xml
This file also has the derby stanza:
<PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
<param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
<param name="schemaObjectPrefix" value="${wsp.name}_"/>
<param name="shutdownOnClose" value="true"/>
</PersistenceManager>
You'll need to change this file as well, it needs to be changed to the same stanza of XML
you used in the repository.xml file.
<PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
<param name="driver" value="org.postgresql.Driver"/>
<param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
<param name="schema" value="postgresql"/>
<param name="user" value="YourUser"/>
<param name="password" value="YourUserPWD"/>
<param name="schemaObjectPrefix" vvalue="jcr_${wsp.name}_"/>
<param name="externalBLOBs" value="false"/>
</PersistenceManager>
This one took a little while to figure out. As it seems to be in the testing hierarchy and so
shouldn't find it's way into the deployed war file, but it does..
It's the source of the following files:
sling/bundles/jcr/resource/target/repository/repository.xml
sling/bundles/jcr/resource/target/repository/workspaces/default/workspace.xml
Finally do a build of Sling..
You will have to disable tests. It seems that the testing process counts on derby to empty
out the database each time a new test is started. As a result, tests fail when you try to build with
Postgres as the back end.
mvn -Dmaven.test.skip=true install
You'll find the typical build artifacts in:
sling/launchpad/builder/target
change the war file from:
org.apache.sling.launchpad-6-SNAPSHOT.war
to:
sling.war
then deploy, in my case, in to glassfish.
I hope that helps someone else who feels the need for a back end that's based on
something other then Derby.
Tony Giaccone
Re: exported... or not?
Posted by Jos Snellings <Jo...@pandora.be>.
Probably I am drastically overlooking something... but when I observe
the exported packages is the springsource xml commons,
the manifest headers look perfectly OK to me, but it seems like Felix is
missing the javax.xml.transform export (1.3.4).
Yet, the necessary classes are in the bundle and the exports are right.
This is what Felix reports about the bundle's imports and exports:
Apache XML Commons XML-APIscom.springsource.org.apache.xmlcommons
<http://localhost:8080/sling/system/console/bundles/71>
Symbolic Name com.springsource.org.apache.xmlcommons
Version 1.3.4
Bundle Location
inputstream:com.springsource.org.apache.xmlcommons-1.3.4.jar
Last Modification Wed Jun 16 08:30:35 CEST 2010
Vendor SpringSource
Start Level 20
Fragments Attached com.springsource.org.apache.xerces (61)
<http://localhost:8080/sling/system/console/bundles/61>
Exported Packages javax.xml,version=1.3.4
javax.xml.xpath,version=1.3.4
org.apache.html.dom,version=2.9.1
org.apache.wml,version=2.9.1
org.apache.wml.dom,version=2.9.1
org.apache.xerces.dom,version=2.9.1
org.apache.xerces.dom.events,version=2.9.1
org.apache.xerces.dom3.as,version=2.9.1
org.apache.xerces.impl,version=2.9.1
org.apache.xerces.impl.dtd,version=2.9.1
org.apache.xerces.impl.dtd.models,version=2.9.1
org.apache.xerces.impl.dv,version=2.9.1
org.apache.xerces.impl.dv.dtd,version=2.9.1
org.apache.xerces.impl.dv.util,version=2.9.1
org.apache.xerces.impl.dv.xs,version=2.9.1
org.apache.xerces.impl.io,version=2.9.1
org.apache.xerces.impl.msg,version=2.9.1
org.apache.xerces.impl.validation,version=2.9.1
org.apache.xerces.impl.xpath,version=2.9.1
org.apache.xerces.impl.xpath.regex,version=2.9.1
org.apache.xerces.impl.xs,version=2.9.1
org.apache.xerces.impl.xs.identity,version=2.9.1
org.apache.xerces.impl.xs.models,version=2.9.1
org.apache.xerces.impl.xs.opti,version=2.9.1
org.apache.xerces.impl.xs.traversers,version=2.9.1
org.apache.xerces.impl.xs.util,version=2.9.1
org.apache.xerces.jaxp,version=2.9.1
org.apache.xerces.jaxp.datatype,version=2.9.1
org.apache.xerces.jaxp.validation,version=2.9.1
org.apache.xerces.parsers,version=2.9.1
org.apache.xerces.util,version=2.9.1
org.apache.xerces.xinclude,version=2.9.1
org.apache.xerces.xni,version=2.9.1
org.apache.xerces.xni.grammars,version=2.9.1
org.apache.xerces.xni.parser,version=2.9.1
org.apache.xerces.xpointer,version=2.9.1
org.apache.xerces.xs,version=2.9.1
org.apache.xerces.xs.datatypes,version=2.9.1
org.apache.xml.serialize,version=2.9.1
org.apache.xmlcommons,version=1.3.4
org.w3c.dom.bootstrap,version=1.3.4
org.w3c.dom.css,version=1.3.4
org.w3c.dom.stylesheets,version=1.3.4
org.w3c.dom.xpath,version=1.3.4
Imported Packages javax.xml.datatype,version=0.0.0 from
org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
javax.xml.namespace,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
javax.xml.parsers,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
javax.xml.transform,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
javax.xml.transform.dom,version=0.0.0 from org.apache.felix.framework
(0) <http://localhost:8080/sling/system/console/bundles/0>
javax.xml.transform.sax,version=0.0.0 from org.apache.felix.framework
(0) <http://localhost:8080/sling/system/console/bundles/0>
javax.xml.transform.stream,version=0.0.0 from org.apache.felix.framework
(0) <http://localhost:8080/sling/system/console/bundles/0>
javax.xml.validation,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.apache.xml.resolver,version=1.2.0 from
com.springsource.org.apache.xml.resolver (64)
<http://localhost:8080/sling/system/console/bundles/64>
org.apache.xml.resolver.readers,version=1.2.0 from
com.springsource.org.apache.xml.resolver (64)
<http://localhost:8080/sling/system/console/bundles/64>
org.w3c.dom,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.w3c.dom.events,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.w3c.dom.html,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.w3c.dom.ls,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.w3c.dom.ranges,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.w3c.dom.traversal,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.w3c.dom.views,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.xml.sax,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.xml.sax.ext,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
org.xml.sax.helpers,version=0.0.0 from org.apache.felix.framework (0)
<http://localhost:8080/sling/system/console/bundles/0>
Manifest Headers Ant-Version: Apache Ant 1.6.5
Bundle-ManifestVersion: 2
Bundle-Name: Apache XML Commons XML-APIs
Bundle-SymbolicName: com.springsource.org.apache.xmlcommons
Bundle-Vendor: SpringSource
Bundle-Version: 1.3.4
Created-By: 1.3.1 (IBM Corporation)
Export-Package: javax.xml; version="1.3.4", javax.xml.datatype;
version="1.3.4"; uses:="javax.xml.namespace", javax.xml.namespace;
version="1.3.4", javax.xml.parsers; version="1.3.4";
uses:="javax.xml.validation, org.w3c.dom, org.xml.sax,
org.xml.sax.helpers", javax.xml.transform; version="1.3.4",
javax.xml.transform.dom; version="1.3.4"; uses:="javax.xml.transform,
org.w3c.dom", javax.xml.transform.sax; version="1.3.4";
uses:="javax.xml.transform, org.xml.sax, org.xml.sax.ext",
javax.xml.transform.stream; version="1.3.4";
uses:="javax.xml.transform", javax.xml.validation; version="1.3.4";
uses:="javax.xml.transform, org.w3c.dom, org.w3c.dom.ls, org.xml.sax",
javax.xml.xpath; version="1.3.4"; uses:="javax.xml.namespace,
org.xml.sax", org.apache.xmlcommons; version="1.3.4", org.w3c.dom;
version="1.3.4", org.w3c.dom.bootstrap; version="1.3.4";
uses:="org.w3c.dom", org.w3c.dom.css; version="1.3.4";
uses:="org.w3c.dom, org.w3c.dom.stylesheets, org.w3c.dom.views",
org.w3c.dom.events; version="1.3.4"; uses:="org.w3c.dom,
org.w3c.dom.views", org.w3c.dom.html; version="1.3.4";
uses:="org.w3c.dom", org.w3c.dom.ls; version="1.3.4";
uses:="org.w3c.dom, org.w3c.dom.events, org.w3c.dom.traversal",
org.w3c.dom.ranges; version="1.3.4"; uses:="org.w3c.dom",
org.w3c.dom.stylesheets; version="1.3.4"; uses:="org.w3c.dom",
org.w3c.dom.traversal; version="1.3.4"; uses:="org.w3c.dom",
org.w3c.dom.views; version="1.3.4", org.w3c.dom.xpath; version="1.3.4";
uses:="org.w3c.dom", org.xml.sax; version="1.3.4", org.xml.sax.ext;
version="1.3.4"; uses:="org.xml.sax, org.xml.sax.helpers",
org.xml.sax.helpers; version="1.3.4"; uses:="org.xml.sax"
Manifest-Version: 1.0
Tool: Bundlor 1.0.0.CI-B166
Re: exported... or not?
Posted by Jos Snellings <Jo...@pandora.be>.
Correction: I just rebuilt from trunk and when I upload bundle
xmlcommons I perfectly get the export or javax.xml.transform.*
(my previous full build was from may 25).
Jos
On 06/15/2010 10:29 AM, Felix Meschberger wrote:
> Hi,
>
>
> On 15.06.2010 10:23, Jos Snellings wrote:
>
>> Yes, I like this version notation very much, time to rebuild the trunk!
>> Then there is the dependency mystery:
>> according to the manifest springsource xml commons 1.3.4 should export:
>> javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax ...
>> but felix console says it does not. What could be the reason?
>>
> I cannot confirm this. When I install this bundle, Web Console 3.0
> happily lists the exports.
>
> Regards
> Felix
>
>
>> Jos
>>
>>
>
>
Re: exported... or not?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 15.06.2010 10:23, Jos Snellings wrote:
> Yes, I like this version notation very much, time to rebuild the trunk!
> Then there is the dependency mystery:
> according to the manifest springsource xml commons 1.3.4 should export:
> javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax ...
> but felix console says it does not. What could be the reason?
I cannot confirm this. When I install this bundle, Web Console 3.0
happily lists the exports.
Regards
Felix
>
> Jos
>
exported... or not?
Posted by Jos Snellings <Jo...@pandora.be>.
Yes, I like this version notation very much, time to rebuild the trunk!
Then there is the dependency mystery:
according to the manifest springsource xml commons 1.3.4 should export:
javax.xml.transform, javax.xml.transform.dom, javax.xml.transform.sax ...
but felix console says it does not. What could be the reason?
Jos
Re: Swapping Postgres for Derby
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 15.06.2010 05:47, Jos Snellings wrote:
> Hi Tony,
>
> From you explanation, this struck me:
> Once this was done the next step was to ensure that the postgres drivers
> got loaded. To get them
>> loaded they must be part of an OSGi bundle. My first attempts to get
>> this working relied on bundles that
>> had been suggested to me from springsource.com
>>
>> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.postgresql.jdbc3&version=8.3.603&searchType=bundlesByName&searchQuery=postgres
>>
>>
>> I was NOT able to get those drivers/bundles working. I don't think the
>> Manifest files contained in those
>> jar files are correct. I burned the better part of two days (I was
>> totally ignorant, and still am mostly
>> ignorant about OSGi). That ignorance only made the process more
>> complicated.
>>
> * several bundles you find on spring source use a particular notation
> for a version interval:
> [v1,v2)
> would by a half-open interval, I assume it says "from v1 including, any
> version to v2, not included"
Exactly. It is good practice to explicitly describe the dependencies in
terms of version intervals to ensure the API contracts.
> Now, the Felix console makes trouble when you request details about the
> bundle. He will complain about "unable to read version".
>
> Anyone knows why that is?
Yes, this is probably due to FELIX-2244 [1] which has been fixed in trunk.
But this is only a problem with the web console not with the framework
not being able to thandle the bundle.
Regards
Felix
>
> What I often notice, as a novice to OSGi as well, is that resolution
> does not always work as I expected.
>
> Cheers,
> Jos
>
Re: Swapping Postgres for Derby
Posted by Jos Snellings <Jo...@pandora.be>.
Hi Tony,
From you explanation, this struck me:
Once this was done the next step was to ensure that the postgres drivers
got loaded. To get them
> loaded they must be part of an OSGi bundle. My first attempts to get this working relied on bundles that
> had been suggested to me from springsource.com
>
> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.postgresql.jdbc3&version=8.3.603&searchType=bundlesByName&searchQuery=postgres
>
> I was NOT able to get those drivers/bundles working. I don't think the Manifest files contained in those
> jar files are correct. I burned the better part of two days (I was totally ignorant, and still am mostly
> ignorant about OSGi). That ignorance only made the process more complicated.
>
* several bundles you find on spring source use a particular notation
for a version interval:
[v1,v2)
would by a half-open interval, I assume it says "from v1 including, any
version to v2, not included"
Now, the Felix console makes trouble when you request details about the
bundle. He will complain about "unable to read version".
Anyone knows why that is?
What I often notice, as a novice to OSGi as well, is that resolution
does not always work as I expected.
Cheers,
Jos
Re: Swapping Postgres for Derby
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 14.06.2010 14:51, Tony Giaccone wrote:
> Felix,
>
> The real point of this exercise was to get Oracle up and running. However, the Oracle server I
> will be using is remote and is protected by a bit of security. Putting postgres on my local box,
> meant I was able to work anywhere, on this problem because everything I needed was local.
Good.
In fact given your description, I actually took me longer to setup
PostgreSQL (install and configure) than to reconfigure Sling [though
PostgreSQL setup is easy by itself on a Linux box ;-) ].
Regards
Felix
>
> I expect to have Oracle functioning later today now that I know how to make the changes,
> getting Launchpad reconfigured should only take a few minutes. :-)
>
>
> Tony
>
>
> On Jun 14, 2010, at 4:12 AM, Felix Meschberger wrote:
>
>> Hi Tony
>>
>> I have to say: hats off to you !
>>
>> Thanks alot for this thorough explanation of your journey to get
>> Postgres support for Sling. Much appreciated.
>>
>> I have created a new page on our site [1] providing these steps to the
>> public. Also I crated an issue [SLING-1556, 2] to ensure optional
>> imports for all JDBC references of Persistence Managers provided by
>> Jackrabbit Core.
>>
>> Regards
>> Felix
>>
>> PS: According to the jdbc.postgresql.org site, the difference between
>> the JDCB3 and JDBC4 driver is, that the JDBC4 driver implements the new
>> methods defined by the JDBC 4 API included with Java 6. If you don't use
>> this new API, you may probably safely use the JDBC 3 driver.
>>
>> [1] http://sling.apache.org/site/jackrabbit-persistence.html
>> [2] https://issues.apache.org/jira/browse/SLING-1556
>>
>> On 11.06.2010 22:14, Tony Giaccone wrote:
>>>
>>> I asked for a bit of assistance to help me swap out the Derby persistence manager in Sling for a
>>> Database backed system.
>>>
>>> I was advised to look at the OSGi bundles for JDBC drivers and to get a better understanding of how
>>> that driver the Felix OSGi container is used by Sling..
>>>
>>>
>>> What follows is the process I used, and how I managed to be successful. I hope that anyone else who
>>> needs to follow this path will find this helpful and give you the specific advice you need to make this
>>> swap out.
>>>
>>> Mind you there are some problems with this path. The main one being that none of the maven testing
>>> works. It looks like this happens because the Derby DB is initialized to blank each time it spins up
>>> while Postgress keeps state. I really haven't looked in detail at why this is, that is just my supposition.
>>> However, I was able to successfully deploy sling into glass fish and create nodes which are backed
>>> by data in the database. For now, that's good enough for me.
>>>
>>>
>>> My intent in this was to do the minimum necessary to get this to work. As a result I have not tried to
>>> remove any of the existing structure that supported using Derby. I that effort was only going to make
>>> the process that more difficult. And made it that much more unlikely to succeed for someone who
>>> knows as little as I do. What I did was augment the build process to include the artifacts necessary to
>>> use the DatabasePersistance manager and Postgres. Once I have this working on my local build,
>>> I'll look into what it takes to do the same, and I expect that will be easy, for Oracle.
>>>
>>>
>>> There is an assumption here that you have a copy of postgres running on your local machine, and that
>>> it's on the standard postgres port and that you have a schema set up for Sling/Jackrabbit to use and an
>>> Postgress userid with access to that database.
>>>
>>> Typical warnings apply, I know very little about Sling or Jackrabbit, I'm about as novice as you can be
>>> with both of these, as a result your milage may vary. I've done no testing on this, the only reason I know
>>> it works is that jackrabbit created the tables in the DB Schema. With all that said here's the process
>>> that seems to be working for me. The sling files I've modified are in bold.
>>>
>>>
>>> The first change I made was to go to a pom file:
>>>
>>> sling/bundles/jcr/jackrabbit-server/pom.xml
>>>
>>> This file is integral to how the derby code gets loaded. So I just duplicated the line but changed it to
>>> the driver for postgresql.
>>>
>>> org.apache.derby.jdbc;resolution:=optional,
>>> org.postgresql.Driver;resolution:=optional,
>>>
>>>
>>> Once this was done the next step was to ensure that the postgres drivers got loaded. To get them
>>> loaded they must be part of an OSGi bundle. My first attempts to get this working relied on bundles that
>>> had been suggested to me from springsource.com
>>>
>>> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.postgresql.jdbc3&version=8.3.603&searchType=bundlesByName&searchQuery=postgres
>>>
>>> I was NOT able to get those drivers/bundles working. I don't think the Manifest files contained in those
>>> jar files are correct. I burned the better part of two days (I was totally ignorant, and still am mostly
>>> ignorant about OSGi). That ignorance only made the process more complicated.
>>>
>>> This pdf helped immensely.
>>>
>>> http://jonas.ow2.org/JONAS_5_2_0_M1/doc/doc-en/pdf/howto_install_jdbc_driver.pdf
>>>
>>>
>>> To get bundles that would work, I did the following. I downloaded the postgres jdbc drivers. I also
>>> downloaded the bnd tool (http://www.aqute.biz/Code/Bnd)
>>>
>>> I used the bnd tool to wrap both sets of drivers.
>>>
>>> $ bnd wrap postgresql-8.4-701.jdbc3.jar
>>> $ mv postgresql-8.4-701.jdbc3.bar postgresql-8.4-701.jdbc3-bnd.jar
>>> $ bnd wrap postgresql-8.4-701.jdbc4.jar
>>> $ mv postgresql-8.4-701.jdbc4.bar postgresql-8.4-701.jdbc4-bnd.jar
>>>
>>> In this way I had both level 3 and level 4 drivers available. I wasn't sure which ones I was going to
>>> need. I then inserted them into my local maven repository.
>>>
>>> $ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc4 \
>>> -Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc4-bnd.jar
>>> $ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc3 \
>>> -Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc3-bnd.jar
>>>
>>> Now the bundles where in my repository, and ready to be used. They have unique names I
>>> appended -bnd to the file names so that they are obviously different. From the jar files.
>>>
>>> To get the jdbc jar files into the right place in launchpad, I had to add the bundle to the build so that
>>> they would be included.
>>>
>>> I did this by modifying this file:
>>>
>>>
>>> sling/launchpad/builder/src/main/bundles/list.xml
>>>
>>> Look for this line:
>>>
>>> <startLevel level="15">
>>>
>>> add this bundle:
>>>
>>> <bundle>
>>> <groupId>postgresql</groupId>
>>> <artifactId>postgresql</artifactId>
>>> <version>8.4.701.jdbc4</version>
>>> </bundle>
>>>
>>> Make the following change:
>>>
>>> in this file:
>>>
>>> sling/bundles/jcr/jackrabbit-server/src/main/resources/repository.xml
>>>
>>> change this stanza of XML (it occurs twice in this file):
>>>
>>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
>>> <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
>>> <param name="schemaObjectPrefix" value="${wsp.name}_"/>
>>> <param name="shutdownOnClose" value="true"/>
>>> </PersistenceManager>
>>>
>>>
>>> To this:
>>>
>>>
>>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
>>> <param name="driver" value="org.postgresql.Driver"/>
>>> <param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
>>> <param name="schema" value="postgresql"/>
>>> <param name="user" value="YourUser"/>
>>> <param name="password" value="YourUserPWD"/>
>>> <param name="schemaObjectPrefix" value="public"/>
>>> <param name="externalBLOBs" value="false"/>
>>> </PersistenceManager>
>>>
>>>
>>>
>>> In this stanza of XML make the following substitutions for your DB
>>>
>>> YourDBSchema is the name of your Postgres Database Schema
>>>
>>> YourUser is the userid of a valid Postgres User
>>> YourUserPwd is the password for that User.
>>>
>>>
>>> You'll need to change one last file:
>>>
>>> bundles/commons/testing/src/main/resources/jackrabbit-test-config.xml
>>>
>>>
>>> This file also has the derby stanza:
>>>
>>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
>>> <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
>>> <param name="schemaObjectPrefix" value="${wsp.name}_"/>
>>> <param name="shutdownOnClose" value="true"/>
>>> </PersistenceManager>
>>>
>>> You'll need to change this file as well, it needs to be changed to the same stanza of XML
>>> you used in the repository.xml file.
>>>
>>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
>>> <param name="driver" value="org.postgresql.Driver"/>
>>> <param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
>>> <param name="schema" value="postgresql"/>
>>> <param name="user" value="YourUser"/>
>>> <param name="password" value="YourUserPWD"/>
>>> <param name="schemaObjectPrefix" vvalue="jcr_${wsp.name}_"/>
>>> <param name="externalBLOBs" value="false"/>
>>> </PersistenceManager>
>>>
>>>
>>> This one took a little while to figure out. As it seems to be in the testing hierarchy and so
>>> shouldn't find it's way into the deployed war file, but it does..
>>>
>>> It's the source of the following files:
>>>
>>> sling/bundles/jcr/resource/target/repository/repository.xml
>>> sling/bundles/jcr/resource/target/repository/workspaces/default/workspace.xml
>>>
>>> Finally do a build of Sling..
>>>
>>> You will have to disable tests. It seems that the testing process counts on derby to empty
>>> out the database each time a new test is started. As a result, tests fail when you try to build with
>>> Postgres as the back end.
>>>
>>> mvn -Dmaven.test.skip=true install
>>>
>>> You'll find the typical build artifacts in:
>>>
>>> sling/launchpad/builder/target
>>>
>>> change the war file from:
>>>
>>> org.apache.sling.launchpad-6-SNAPSHOT.war
>>>
>>> to:
>>> sling.war
>>>
>>> then deploy, in my case, in to glassfish.
>>>
>>>
>>> I hope that helps someone else who feels the need for a back end that's based on
>>> something other then Derby.
>>>
>>>
>>>
>>> Tony Giaccone
>
>
Re: Swapping Postgres for Derby
Posted by Tony Giaccone <tg...@masslight.net>.
Felix,
The real point of this exercise was to get Oracle up and running. However, the Oracle server I
will be using is remote and is protected by a bit of security. Putting postgres on my local box,
meant I was able to work anywhere, on this problem because everything I needed was local.
I expect to have Oracle functioning later today now that I know how to make the changes,
getting Launchpad reconfigured should only take a few minutes. :-)
Tony
On Jun 14, 2010, at 4:12 AM, Felix Meschberger wrote:
> Hi Tony
>
> I have to say: hats off to you !
>
> Thanks alot for this thorough explanation of your journey to get
> Postgres support for Sling. Much appreciated.
>
> I have created a new page on our site [1] providing these steps to the
> public. Also I crated an issue [SLING-1556, 2] to ensure optional
> imports for all JDBC references of Persistence Managers provided by
> Jackrabbit Core.
>
> Regards
> Felix
>
> PS: According to the jdbc.postgresql.org site, the difference between
> the JDCB3 and JDBC4 driver is, that the JDBC4 driver implements the new
> methods defined by the JDBC 4 API included with Java 6. If you don't use
> this new API, you may probably safely use the JDBC 3 driver.
>
> [1] http://sling.apache.org/site/jackrabbit-persistence.html
> [2] https://issues.apache.org/jira/browse/SLING-1556
>
> On 11.06.2010 22:14, Tony Giaccone wrote:
>>
>> I asked for a bit of assistance to help me swap out the Derby persistence manager in Sling for a
>> Database backed system.
>>
>> I was advised to look at the OSGi bundles for JDBC drivers and to get a better understanding of how
>> that driver the Felix OSGi container is used by Sling..
>>
>>
>> What follows is the process I used, and how I managed to be successful. I hope that anyone else who
>> needs to follow this path will find this helpful and give you the specific advice you need to make this
>> swap out.
>>
>> Mind you there are some problems with this path. The main one being that none of the maven testing
>> works. It looks like this happens because the Derby DB is initialized to blank each time it spins up
>> while Postgress keeps state. I really haven't looked in detail at why this is, that is just my supposition.
>> However, I was able to successfully deploy sling into glass fish and create nodes which are backed
>> by data in the database. For now, that's good enough for me.
>>
>>
>> My intent in this was to do the minimum necessary to get this to work. As a result I have not tried to
>> remove any of the existing structure that supported using Derby. I that effort was only going to make
>> the process that more difficult. And made it that much more unlikely to succeed for someone who
>> knows as little as I do. What I did was augment the build process to include the artifacts necessary to
>> use the DatabasePersistance manager and Postgres. Once I have this working on my local build,
>> I'll look into what it takes to do the same, and I expect that will be easy, for Oracle.
>>
>>
>> There is an assumption here that you have a copy of postgres running on your local machine, and that
>> it's on the standard postgres port and that you have a schema set up for Sling/Jackrabbit to use and an
>> Postgress userid with access to that database.
>>
>> Typical warnings apply, I know very little about Sling or Jackrabbit, I'm about as novice as you can be
>> with both of these, as a result your milage may vary. I've done no testing on this, the only reason I know
>> it works is that jackrabbit created the tables in the DB Schema. With all that said here's the process
>> that seems to be working for me. The sling files I've modified are in bold.
>>
>>
>> The first change I made was to go to a pom file:
>>
>> sling/bundles/jcr/jackrabbit-server/pom.xml
>>
>> This file is integral to how the derby code gets loaded. So I just duplicated the line but changed it to
>> the driver for postgresql.
>>
>> org.apache.derby.jdbc;resolution:=optional,
>> org.postgresql.Driver;resolution:=optional,
>>
>>
>> Once this was done the next step was to ensure that the postgres drivers got loaded. To get them
>> loaded they must be part of an OSGi bundle. My first attempts to get this working relied on bundles that
>> had been suggested to me from springsource.com
>>
>> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.postgresql.jdbc3&version=8.3.603&searchType=bundlesByName&searchQuery=postgres
>>
>> I was NOT able to get those drivers/bundles working. I don't think the Manifest files contained in those
>> jar files are correct. I burned the better part of two days (I was totally ignorant, and still am mostly
>> ignorant about OSGi). That ignorance only made the process more complicated.
>>
>> This pdf helped immensely.
>>
>> http://jonas.ow2.org/JONAS_5_2_0_M1/doc/doc-en/pdf/howto_install_jdbc_driver.pdf
>>
>>
>> To get bundles that would work, I did the following. I downloaded the postgres jdbc drivers. I also
>> downloaded the bnd tool (http://www.aqute.biz/Code/Bnd)
>>
>> I used the bnd tool to wrap both sets of drivers.
>>
>> $ bnd wrap postgresql-8.4-701.jdbc3.jar
>> $ mv postgresql-8.4-701.jdbc3.bar postgresql-8.4-701.jdbc3-bnd.jar
>> $ bnd wrap postgresql-8.4-701.jdbc4.jar
>> $ mv postgresql-8.4-701.jdbc4.bar postgresql-8.4-701.jdbc4-bnd.jar
>>
>> In this way I had both level 3 and level 4 drivers available. I wasn't sure which ones I was going to
>> need. I then inserted them into my local maven repository.
>>
>> $ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc4 \
>> -Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc4-bnd.jar
>> $ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc3 \
>> -Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc3-bnd.jar
>>
>> Now the bundles where in my repository, and ready to be used. They have unique names I
>> appended -bnd to the file names so that they are obviously different. From the jar files.
>>
>> To get the jdbc jar files into the right place in launchpad, I had to add the bundle to the build so that
>> they would be included.
>>
>> I did this by modifying this file:
>>
>>
>> sling/launchpad/builder/src/main/bundles/list.xml
>>
>> Look for this line:
>>
>> <startLevel level="15">
>>
>> add this bundle:
>>
>> <bundle>
>> <groupId>postgresql</groupId>
>> <artifactId>postgresql</artifactId>
>> <version>8.4.701.jdbc4</version>
>> </bundle>
>>
>> Make the following change:
>>
>> in this file:
>>
>> sling/bundles/jcr/jackrabbit-server/src/main/resources/repository.xml
>>
>> change this stanza of XML (it occurs twice in this file):
>>
>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
>> <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
>> <param name="schemaObjectPrefix" value="${wsp.name}_"/>
>> <param name="shutdownOnClose" value="true"/>
>> </PersistenceManager>
>>
>>
>> To this:
>>
>>
>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
>> <param name="driver" value="org.postgresql.Driver"/>
>> <param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
>> <param name="schema" value="postgresql"/>
>> <param name="user" value="YourUser"/>
>> <param name="password" value="YourUserPWD"/>
>> <param name="schemaObjectPrefix" value="public"/>
>> <param name="externalBLOBs" value="false"/>
>> </PersistenceManager>
>>
>>
>>
>> In this stanza of XML make the following substitutions for your DB
>>
>> YourDBSchema is the name of your Postgres Database Schema
>>
>> YourUser is the userid of a valid Postgres User
>> YourUserPwd is the password for that User.
>>
>>
>> You'll need to change one last file:
>>
>> bundles/commons/testing/src/main/resources/jackrabbit-test-config.xml
>>
>>
>> This file also has the derby stanza:
>>
>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
>> <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
>> <param name="schemaObjectPrefix" value="${wsp.name}_"/>
>> <param name="shutdownOnClose" value="true"/>
>> </PersistenceManager>
>>
>> You'll need to change this file as well, it needs to be changed to the same stanza of XML
>> you used in the repository.xml file.
>>
>> <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
>> <param name="driver" value="org.postgresql.Driver"/>
>> <param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
>> <param name="schema" value="postgresql"/>
>> <param name="user" value="YourUser"/>
>> <param name="password" value="YourUserPWD"/>
>> <param name="schemaObjectPrefix" vvalue="jcr_${wsp.name}_"/>
>> <param name="externalBLOBs" value="false"/>
>> </PersistenceManager>
>>
>>
>> This one took a little while to figure out. As it seems to be in the testing hierarchy and so
>> shouldn't find it's way into the deployed war file, but it does..
>>
>> It's the source of the following files:
>>
>> sling/bundles/jcr/resource/target/repository/repository.xml
>> sling/bundles/jcr/resource/target/repository/workspaces/default/workspace.xml
>>
>> Finally do a build of Sling..
>>
>> You will have to disable tests. It seems that the testing process counts on derby to empty
>> out the database each time a new test is started. As a result, tests fail when you try to build with
>> Postgres as the back end.
>>
>> mvn -Dmaven.test.skip=true install
>>
>> You'll find the typical build artifacts in:
>>
>> sling/launchpad/builder/target
>>
>> change the war file from:
>>
>> org.apache.sling.launchpad-6-SNAPSHOT.war
>>
>> to:
>> sling.war
>>
>> then deploy, in my case, in to glassfish.
>>
>>
>> I hope that helps someone else who feels the need for a back end that's based on
>> something other then Derby.
>>
>>
>>
>> Tony Giaccone
Re: Swapping Postgres for Derby
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Tony
I have to say: hats off to you !
Thanks alot for this thorough explanation of your journey to get
Postgres support for Sling. Much appreciated.
I have created a new page on our site [1] providing these steps to the
public. Also I crated an issue [SLING-1556, 2] to ensure optional
imports for all JDBC references of Persistence Managers provided by
Jackrabbit Core.
Regards
Felix
PS: According to the jdbc.postgresql.org site, the difference between
the JDCB3 and JDBC4 driver is, that the JDBC4 driver implements the new
methods defined by the JDBC 4 API included with Java 6. If you don't use
this new API, you may probably safely use the JDBC 3 driver.
[1] http://sling.apache.org/site/jackrabbit-persistence.html
[2] https://issues.apache.org/jira/browse/SLING-1556
On 11.06.2010 22:14, Tony Giaccone wrote:
>
> I asked for a bit of assistance to help me swap out the Derby persistence manager in Sling for a
> Database backed system.
>
> I was advised to look at the OSGi bundles for JDBC drivers and to get a better understanding of how
> that driver the Felix OSGi container is used by Sling..
>
>
> What follows is the process I used, and how I managed to be successful. I hope that anyone else who
> needs to follow this path will find this helpful and give you the specific advice you need to make this
> swap out.
>
> Mind you there are some problems with this path. The main one being that none of the maven testing
> works. It looks like this happens because the Derby DB is initialized to blank each time it spins up
> while Postgress keeps state. I really haven't looked in detail at why this is, that is just my supposition.
> However, I was able to successfully deploy sling into glass fish and create nodes which are backed
> by data in the database. For now, that's good enough for me.
>
>
> My intent in this was to do the minimum necessary to get this to work. As a result I have not tried to
> remove any of the existing structure that supported using Derby. I that effort was only going to make
> the process that more difficult. And made it that much more unlikely to succeed for someone who
> knows as little as I do. What I did was augment the build process to include the artifacts necessary to
> use the DatabasePersistance manager and Postgres. Once I have this working on my local build,
> I'll look into what it takes to do the same, and I expect that will be easy, for Oracle.
>
>
> There is an assumption here that you have a copy of postgres running on your local machine, and that
> it's on the standard postgres port and that you have a schema set up for Sling/Jackrabbit to use and an
> Postgress userid with access to that database.
>
> Typical warnings apply, I know very little about Sling or Jackrabbit, I'm about as novice as you can be
> with both of these, as a result your milage may vary. I've done no testing on this, the only reason I know
> it works is that jackrabbit created the tables in the DB Schema. With all that said here's the process
> that seems to be working for me. The sling files I've modified are in bold.
>
>
> The first change I made was to go to a pom file:
>
> sling/bundles/jcr/jackrabbit-server/pom.xml
>
> This file is integral to how the derby code gets loaded. So I just duplicated the line but changed it to
> the driver for postgresql.
>
> org.apache.derby.jdbc;resolution:=optional,
> org.postgresql.Driver;resolution:=optional,
>
>
> Once this was done the next step was to ensure that the postgres drivers got loaded. To get them
> loaded they must be part of an OSGi bundle. My first attempts to get this working relied on bundles that
> had been suggested to me from springsource.com
>
> http://www.springsource.com/repository/app/bundle/version/detail?name=com.springsource.org.postgresql.jdbc3&version=8.3.603&searchType=bundlesByName&searchQuery=postgres
>
> I was NOT able to get those drivers/bundles working. I don't think the Manifest files contained in those
> jar files are correct. I burned the better part of two days (I was totally ignorant, and still am mostly
> ignorant about OSGi). That ignorance only made the process more complicated.
>
> This pdf helped immensely.
>
> http://jonas.ow2.org/JONAS_5_2_0_M1/doc/doc-en/pdf/howto_install_jdbc_driver.pdf
>
>
> To get bundles that would work, I did the following. I downloaded the postgres jdbc drivers. I also
> downloaded the bnd tool (http://www.aqute.biz/Code/Bnd)
>
> I used the bnd tool to wrap both sets of drivers.
>
> $ bnd wrap postgresql-8.4-701.jdbc3.jar
> $ mv postgresql-8.4-701.jdbc3.bar postgresql-8.4-701.jdbc3-bnd.jar
> $ bnd wrap postgresql-8.4-701.jdbc4.jar
> $ mv postgresql-8.4-701.jdbc4.bar postgresql-8.4-701.jdbc4-bnd.jar
>
> In this way I had both level 3 and level 4 drivers available. I wasn't sure which ones I was going to
> need. I then inserted them into my local maven repository.
>
> $ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc4 \
> -Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc4-bnd.jar
> $ mvn install:install-file -DgroupId=postgresql -DartifactId=postgresql -Dversion=8.4.701.jdbc3 \
> -Dpackaging=jar -Dfile=postgresql-8.4-701.jdbc3-bnd.jar
>
> Now the bundles where in my repository, and ready to be used. They have unique names I
> appended -bnd to the file names so that they are obviously different. From the jar files.
>
> To get the jdbc jar files into the right place in launchpad, I had to add the bundle to the build so that
> they would be included.
>
> I did this by modifying this file:
>
>
> sling/launchpad/builder/src/main/bundles/list.xml
>
> Look for this line:
>
> <startLevel level="15">
>
> add this bundle:
>
> <bundle>
> <groupId>postgresql</groupId>
> <artifactId>postgresql</artifactId>
> <version>8.4.701.jdbc4</version>
> </bundle>
>
> Make the following change:
>
> in this file:
>
> sling/bundles/jcr/jackrabbit-server/src/main/resources/repository.xml
>
> change this stanza of XML (it occurs twice in this file):
>
> <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
> <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
> <param name="schemaObjectPrefix" value="${wsp.name}_"/>
> <param name="shutdownOnClose" value="true"/>
> </PersistenceManager>
>
>
> To this:
>
>
> <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
> <param name="driver" value="org.postgresql.Driver"/>
> <param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
> <param name="schema" value="postgresql"/>
> <param name="user" value="YourUser"/>
> <param name="password" value="YourUserPWD"/>
> <param name="schemaObjectPrefix" value="public"/>
> <param name="externalBLOBs" value="false"/>
> </PersistenceManager>
>
>
>
> In this stanza of XML make the following substitutions for your DB
>
> YourDBSchema is the name of your Postgres Database Schema
>
> YourUser is the userid of a valid Postgres User
> YourUserPwd is the password for that User.
>
>
> You'll need to change one last file:
>
> bundles/commons/testing/src/main/resources/jackrabbit-test-config.xml
>
>
> This file also has the derby stanza:
>
> <PersistenceManager class="org.apache.jackrabbit.core.persistence.db.DerbyPersistenceManager">
> <param name="url" value="jdbc:derby:${wsp.home}/db;create=true"/>
> <param name="schemaObjectPrefix" value="${wsp.name}_"/>
> <param name="shutdownOnClose" value="true"/>
> </PersistenceManager>
>
> You'll need to change this file as well, it needs to be changed to the same stanza of XML
> you used in the repository.xml file.
>
> <PersistenceManager class="org.apache.jackrabbit.core.persistence.bundle.PostgreSQLPersistenceManager">
> <param name="driver" value="org.postgresql.Driver"/>
> <param name="url" value="jdbc:postgresql://localhost:5432/YourDBSchema"/>
> <param name="schema" value="postgresql"/>
> <param name="user" value="YourUser"/>
> <param name="password" value="YourUserPWD"/>
> <param name="schemaObjectPrefix" vvalue="jcr_${wsp.name}_"/>
> <param name="externalBLOBs" value="false"/>
> </PersistenceManager>
>
>
> This one took a little while to figure out. As it seems to be in the testing hierarchy and so
> shouldn't find it's way into the deployed war file, but it does..
>
> It's the source of the following files:
>
> sling/bundles/jcr/resource/target/repository/repository.xml
> sling/bundles/jcr/resource/target/repository/workspaces/default/workspace.xml
>
> Finally do a build of Sling..
>
> You will have to disable tests. It seems that the testing process counts on derby to empty
> out the database each time a new test is started. As a result, tests fail when you try to build with
> Postgres as the back end.
>
> mvn -Dmaven.test.skip=true install
>
> You'll find the typical build artifacts in:
>
> sling/launchpad/builder/target
>
> change the war file from:
>
> org.apache.sling.launchpad-6-SNAPSHOT.war
>
> to:
> sling.war
>
> then deploy, in my case, in to glassfish.
>
>
> I hope that helps someone else who feels the need for a back end that's based on
> something other then Derby.
>
>
>
> Tony Giaccone