[Geoserver-devel] Embedding a customized geoserver/config via a Maven MOJO Plugin?

Andrew_Hughes · April 14, 2008, 5:11am

Hi All,

I’ve tried to find the “best fit” solution to what I think is a fairly common problem:

My WebApp (war) needs to call a customized geoserver. Specifically, I want my geoserver deployed with my own data, styles, user/pass eta eta eta…

From everything I can see, I should configure the appserver to have -DGEOSERVER_DATA_DIR and that’s the “customized” config I require (can redeploy a new zip to the machine eta eta eta). However, this isn’t the easiest thing to do from an operational sense… it would be much easier if I could deploy my geoserver_data within the geoserver.war itself. After all, its what war’s are there for.

So, I’ve given this some thought and seen a similar approach in other projects. Maven mojo plugins often download resources from zip’s, unpack them, use the contents of the unpacked artifact, repackage and then release/distrubute/deployed eta eta eta.

If geoserver.war is available in a maven repository(?) it can be downloaded (version specific) as a plugin dependency, it can be unpacked (target/geoserver/*), and the contents of the data dir can be replaced by the contents the client user wants/has. This means that I can release my own spatial data and server with all the benefits of svn, geoserver and Maven’s lifecycle. It also means that the war can be packed inside an ear to be coupled with your applications versioning/release cycle eta eta eta (another great way to deploy an application that is dependent on a specific geoserver version or config).

I’m sure there are other ways around this too, where I might checkout geoserver src as a module in my own project, and customize it there… from a “once off” perspecitve that might be a “quicker”… but doesn’t represent an easy solution for the next person that wants to do this. It also makes versioning of the geoserver dependency painful.

Thoughts?

Andrea_Aime3 · April 14, 2008, 7:39am

Andrew Hughes ha scritto:

Hi All,

I've tried to find the "best fit" solution to what I think is a fairly common problem:

My WebApp (war) needs to call a customized geoserver. Specifically, I want my geoserver deployed with my own data, styles, user/pass eta eta eta....

From everything I can see, I should configure the appserver to have -DGEOSERVER_DATA_DIR and that's the "customized" config I require (can redeploy a new zip to the machine eta eta eta). However, this isn't the easiest thing to do from an operational sense... it would be much easier if I could deploy my geoserver_data within the geoserver.war itself. After all, its what war's are there for.

So, I've given this some thought and seen a similar approach in other projects. Maven mojo plugins often download resources from zip's, unpack them, use the contents of the unpacked artifact, repackage and then release/distrubute/deployed eta eta eta.

If geoserver.war is available in a maven repository(?) it can be downloaded (version specific) as a plugin dependency, it can be unpacked (target/geoserver/*), and the contents of the data dir can be replaced by the contents the client user wants/has. This means that I can release my own spatial data and server with all the benefits of svn, geoserver and Maven's lifecycle. It also means that the war can be packed inside an ear to be coupled with your applications versioning/release cycle eta eta eta (another great way to deploy an application that is dependent on a specific geoserver version or config).

I'm sure there are other ways around this too, where I might checkout geoserver src as a module in my own project, and customize it there.... from a "once off" perspecitve that might be a "quicker"... but doesn't represent an easy solution for the next person that wants to do this. It also makes versioning of the geoserver dependency painful.

We don't have any support for fiddling with the generated .war, and it's
not published on any repository either afaik... how would you depend
on a .war? Maven dependency mechanism is made for classpath dependencies.

Anyways, if you check out the sources, you can build geoserver with
mvn clean install -DconfigDirectory=/path/to/the/parent/of/the/data/dir
-DconfigId=dataDirName
and you'll get a geoserver.war that has the data dir you pointed
the build at

Cheers
Andrea

Andrew_Hughes · April 14, 2008, 11:53pm

Hi Guys,

I’ve looked into this a little and found a few things out…

A war can most certainly be a dependency, and dependency:unpack can be used to unpack it (providing the dependency is hosted in a repository).
Providing we make a mojo plugin available, the unpacked ./data directory can be replaced by that of the local project/module. (./src/main/config)
This can be done starting up an embedded app server (jetty/tomcat/whatever see maven cargo) with the geoserver war and -DGEOSERVER_DATA_DIR=${basedir}/src/main/config
It’s would also be possible to run an embedded appserver+geoserver inside maven, so “out of the box” spatial data development/configuration/testing/hosting of (.src/main/config) is available.
The geoserver.war can be repacked with the newly developed (./src/main/config) spatial data/configuration replacing ./data

The above would be pretty neat for those wishing to package/version/release/develop applications to spatial data, as well as ear releases.

More Thoughts?

ps for anyone wanting a vague reference of this, I’ve worked on the gwt-maven 2 sample project (but can’t take credit for the magic behind the scene). This project can download a gwt release as a dependency (either win,linux or mac)… unpack gwt, configure all the application sources for the gwt shell to run (this is an embedded tomcat with special features). End result, is that gwt runs out of the box for developing your own customer applications, the same thing we could achieve with geoserver. So very similar benefits could be made available to geoserver users and thus increase it’s maven user base.

You can try the gwt example as below:

svn export http://gwt-maven.googlecode.com/svn/trunk/maven-googlewebtoolkit2-sample
cd maven-googlewebtoolkit2-sample
mvn install
cd war
mvn gwt:gwt

On Mon, Apr 14, 2008 at 5:09 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:

Hi All,

I’ve tried to find the “best fit” solution to what I think is a fairly common problem:

My WebApp (war) needs to call a customized geoserver. Specifically, I want my geoserver deployed with my own data, styles, user/pass eta eta eta…

From everything I can see, I should configure the appserver to have -DGEOSERVER_DATA_DIR and that’s the “customized” config I require (can redeploy a new zip to the machine eta eta eta). However, this isn’t the easiest thing to do from an operational sense… it would be much easier if I could deploy my geoserver_data within the geoserver.war itself. After all, its what war’s are there for.

So, I’ve given this some thought and seen a similar approach in other projects. Maven mojo plugins often download resources from zip’s, unpack them, use the contents of the unpacked artifact, repackage and then release/distrubute/deployed eta eta eta.

If geoserver.war is available in a maven repository(?) it can be downloaded (version specific) as a plugin dependency, it can be unpacked (target/geoserver/*), and the contents of the data dir can be replaced by the contents the client user wants/has. This means that I can release my own spatial data and server with all the benefits of svn, geoserver and Maven’s lifecycle. It also means that the war can be packed inside an ear to be coupled with your applications versioning/release cycle eta eta eta (another great way to deploy an application that is dependent on a specific geoserver version or config).

I’m sure there are other ways around this too, where I might checkout geoserver src as a module in my own project, and customize it there… from a “once off” perspecitve that might be a “quicker”… but doesn’t represent an easy solution for the next person that wants to do this. It also makes versioning of the geoserver dependency painful.

We don’t have any support for fiddling with the generated .war, and it’s
not published on any repository either afaik… how would you depend
on a .war? Maven dependency mechanism is made for classpath dependencies.

Anyways, if you check out the sources, you can build geoserver with
mvn clean install -DconfigDirectory=/path/to/the/parent/of/the/data/dir
-DconfigId=dataDirName
and you’ll get a geoserver.war that has the data dir you pointed
the build at

Cheers
Andrea

Andrea_Aime3 · April 15, 2008, 7:46am

Andrew Hughes ha scritto:

Hi Guys,

I've looked into this a little and found a few things out...

   1. A war can most certainly be a dependency, and dependency:unpack
      can be used to unpack it (providing the dependency is hosted in a
      repository).

Hum, ok, but I don't know how to push a .war onto a repository... I'm
not even sure we would like to do so. Each .war is 30MB, we'd have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

   2. Providing we make a mojo plugin available, the unpacked ./data
      directory can be replaced by that of the local project/module. (./src/main/config) 1. This can be done starting up an embedded app server
            (jetty/tomcat/whatever see maven cargo) with the geoserver
            war and -DGEOSERVER_DATA_DIR=${basedir}/src/main/config
   3. It's would also be possible to run an embedded appserver+geoserver
      inside maven, so "out of the box" spatial data
      development/configuration/testing/hosting of (.src/main/config) is
      available.
   4. The geoserver.war can be repacked with the newly developed
      (./src/main/config) spatial data/configuration replacing ./data

Hum, this sounds like a good candidate for a community module. Interested in working on it and providing some guidance on how to use it in the
wiki?

Cheers
Andrea

Andrew_Hughes · April 15, 2008, 11:37am

On Tue, Apr 15, 2008 at 5:16 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:

Hi Guys,

I’ve looked into this a little and found a few things out…

A war can most certainly be a dependency, and dependency:unpack
can be used to unpack it (providing the dependency is hosted in a
repository).

Hum, ok, but I don’t know how to push a .war onto a repository… I’m
not even sure we would like to do so. Each .war is 30MB, we’d have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

I would have to say, that this should really only be used with releases and not SNAPSHOTS, but of course we all like to test.

Providing we make a mojo plugin available, the unpacked ./data
directory can be replaced by that of the local project/module. (./src/main/config) 1. This can be done starting up an embedded app server

(jetty/tomcat/whatever see maven cargo) with the geoserver
war and -DGEOSERVER_DATA_DIR=${basedir}/src/main/config

It’s would also be possible to run an embedded appserver+geoserver
inside maven, so “out of the box” spatial data
development/configuration/testing/hosting of (.src/main/config) is
available.

The geoserver.war can be repacked with the newly developed
(./src/main/config) spatial data/configuration replacing ./data

Hum, this sounds like a good candidate for a community module. Interested in working on it and providing some guidance on how to use it in the
wiki?

I will try to find some time to see how complex this is in the next couple of days.

Cheers
Andrea

Andrea_Aime3 · April 15, 2008, 1:26pm

Andrew Hughes ha scritto:
...

    Hum, ok, but I don't know how to push a .war onto a repository... I'm
    not even sure we would like to do so. Each .war is 30MB, we'd have to
    make sure the .war are pushed onto the repo only during the release
    process (as opposed to publishing them daily as we for, for instance,
    with the geotools jars)

I would have to say, that this *should* really only be used with releases and not SNAPSHOTS, but of course we all like to test.

Very much agreed... thought I have no idea how to make a .war be deployed, nor how to make an artifact be deployed only during the release... probably using some profile...

    Hum, this sounds like a good candidate for a community module.
    Interested in working on it and providing some guidance on how to
    use it in the
    wiki?

I will try to find some time to see how complex this is in the next couple of days.

Nice. Looking forward to hear your findings.
Cheers
Andrea

Andrew_Hughes · April 18, 2008, 5:22am

Well, I most certainly have found some good news!

I’ll confirm this with some more testing…

If you have a maven war project with, a dependency on a war (ie geoserver)… the geoserver war’s contents are packed into the war as well. This means if you wanted to customize your own… all you would need to do would be to put your geoserver data in ./src/main/webapp/data/*

It would be especially easy if there was a classified version of geoserver available in a maven repository (geoserver-1.6.3-nodata.war), which is easy enough for me to knock up for testing… but I don’t know how this effects your release mechanism if you want to do it in your project?

Next, I will look at how to embed a jetty or tomcat to launch geoserver from the command line. mvn geoserver:start or something.

On Tue, Apr 15, 2008 at 10:56 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:
…

Hum, ok, but I don’t know how to push a .war onto a repository… I’m
not even sure we would like to do so. Each .war is 30MB, we’d have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

I would have to say, that this should really only be used with releases and not SNAPSHOTS, but of course we all like to test.

Very much agreed… thought I have no idea how to make a .war be deployed, nor how to make an artifact be deployed only during the release… probably using some profile…

Hum, this sounds like a good candidate for a community module.
Interested in working on it and providing some guidance on how to
use it in the
wiki?

I will try to find some time to see how complex this is in the next couple of days.

Nice. Looking forward to hear your findings.
Cheers
Andrea

Ben_Caradoc-Davies · April 18, 2008, 5:26am

Andrew Hughes wrote:

Next, I will look at how to embed a jetty or tomcat to launch geoserver from
the command line. mvn geoserver:start or something.

The manual suggests "mvn jetty:run".

http://geoserver.org/display/GEOSDOC/2+Maven+Quickstart

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

Andrea_Aime3 · April 18, 2008, 8:27am

Andrew Hughes ha scritto:

Well, I most certainly have found some good news!

I'll confirm this with some more testing...

If you have a maven <packaging>war</packaging> project with, a dependency on a war (ie geoserver)... the geoserver war's contents are packed into the war as well. This means if you wanted to customize your own... all you would need to do would be to put your geoserver data in ./src/main/webapp/data/*

Hum, that's what the config plugin we have in GeoServer does when
you run "mvn install -DconfigId=myconfig -DconfigDirectory=/path/to/config/dir/parent"

I assumed you already knew about this?

It would be especially easy if there was a classified version of geoserver available in a maven repository (geoserver-1.6.3-nodata.war), which is easy enough for me to knock up for testing... but I don't know how this effects your release mechanism if you want to do it in your project?

Hem... we definitely do not publish the .war now and I still don't know
how this would happen. We do deploye on the codehaus repo and the web
module gets published as a jar (i.e. web-1.6.2.jar, 32MB... hmmm...):
http://repository.codehaus.org/org/geoserver/web/1.6.2/

Yet, if you don't manually install anything,
by default you get the empty data dir (which is not the same a no data).

Next, I will look at how to embed a jetty or tomcat to launch geoserver from the command line. mvn geoserver:start or something.

I suggest you look in the geoserver sources, it seems there
is most of what you need... I think you want to make something
separated from GeoServer that allows people customization without
needing to check out the sources, right?

Cheers
Andrea

Andrew_Hughes · April 18, 2008, 12:21pm

Hi,

I got all the stuff I wanted working… will post soln on monday, you will be suprised how easy it was.

As you said…

I suggest you look in the geoserver sources, it seems there
is most of what you need… I think you want to make something
separated from GeoServer that allows people customization without
needing to check out the sources, right?

This is true but is really a link in the chain for what I am trying to achieve. What I really want to do, is to EASILY associate my spatial web applications with a customized geoserver configuration/data release. In doing so, I can release a new instance of my spatial application and its supporting spatial services/data/config at the same time. FYI: I will most likely do this via an ear.

My multi-module maven project might look like:

mycompany.spatial:mycompany-spatial
mycompany.spatial:geoserver (this module produces a geoserver.war with my data/content)
mycomapny.spatial:phonebox-mapper-war (a web app that http calls the geoserver^)
mycomapny.spatial:atm-finder-war (another web app that http calls the geoserver^)
mycomapny.spatial:geo-tagger-war (yet another…)
mycompany.spatial:ear (an ear project that packs all of the above into a single release artifact)

And sure, you might want to add geotool’s as a dependency in the war’s so that they can talk nicely to geoserver.

The important fact, is that a customized geoserver can easily be embedded/consumed/deployed in the same development lifecycle as the web app that will be consuming its services. No messy forking of application and service lifecycles.

Futher more, the jetty runner can run a geoserver “out of the box”, so the non-savvy spatial developer has lower ramp up time writing their spatial webapp.

As far as releasing the application goes… you already do “mvn release:prepare release:perform” by the looks of it… so you already have a maven repository (http://repository.codehaus.org/org/geoserver/web/) there’s a few options, either a nodata classified release at the same time (I believe this is e-a-s-y). Or something that is definately easy is your “mvn install -DconfigId=myconfig -DconfigDirectory=/path/to/config/dir/parent” process “hard coded” to produce and empty data dir in a new module. “web-nodata” perhaps?

Anyway, what I have is working awesome and I will share when I’m back in the office on monday.

–AH

On Fri, Apr 18, 2008 at 5:57 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:

Well, I most certainly have found some good news!

I’ll confirm this with some more testing…

If you have a maven war project with, a dependency on a war (ie geoserver)… the geoserver war’s contents are packed into the war as well. This means if you wanted to customize your own… all you would need to do would be to put your geoserver data in ./src/main/webapp/data/*

Hum, that’s what the config plugin we have in GeoServer does when
you run “mvn install -DconfigId=myconfig -DconfigDirectory=/path/to/config/dir/parent”

I assumed you already knew about this?

Yes, but this is your application lifecycle, not mine

It would be especially easy if there was a classified version of geoserver available in a maven repository (geoserver-1.6.3-nodata.war), which is easy enough for me to knock up for testing… but I don’t know how this effects your release mechanism if you want to do it in your project?

Hem… we definitely do not publish the .war now and I still don’t know
how this would happen. We do deploye on the codehaus repo and the web
module gets published as a jar (i.e. web-1.6.2.jar, 32MB… hmmm…):
http://repository.codehaus.org/org/geoserver/web/1.6.2/

Yet, if you don’t manually install anything,
by default you get the empty data dir (which is not the same a no data).

http://svn.codehaus.org/geoserver/trunk/geoserver/web/pom.xml = jar
^Seems odd. Plus I can’t see any other war pom’s in any other modules either.

Next, I will look at how to embed a jetty or tomcat to launch geoserver from the command line. mvn geoserver:start or something.

I suggest you look in the geoserver sources, it seems there
is most of what you need… I think you want to make something
separated from GeoServer that allows people customization without
needing to check out the sources, right?

Cheers
Andrea

Andrew_Hughes · April 23, 2008, 12:53am

Ok Guys… Here Goes…

apologies this is off the top of my head and on not on my dev machine to test right now…

Create a copy of geoserver, with an empty data dir. - geoserver “nodata”. (In future this should be in a public repo already)
download geoserver.war (I used v1.6.3)
extract the contents with jar -xvf geoserver.war
take a backup of the /data dir… cp -Rv ./data /tmp/. (you will need this later)
remove the contents of the data dir… rm -rf ./data/*
remove original geoserver.war rm -rf geoserver.war
repack into new war, without data… jar -cvf jar -xvf geoserver-1.6.0-nodata.war *
Install the nodata geoserver in the local maven repo (~/.m2/repository/) (In future this should be in a public repo already)
mvn install:install-file -Dfile=geoserver-1.6.3-nodata.war -DgroupId=org.geoserver -DartifactId=geoserver -Dversion=1.6.3 -Dpackaging=war -Dclassifier=nodata -DgeneratePom=true -DcreateChecksum=true
Create a Maven project that uses the above… and containts geoserver_data_dir contents. (In future this is the only part required by a developer if geoserver-nodata is hosted in a public repo - in fact a customer archetype could fix this too).
mkdir ./mygeoserver
mkdir(s) ./mygeoserver/src/main/webapp/data
cp -Rv /tmp/data/. (this is the backup you took earlier)
create ./mygeoserver/pom.xml (attached below)1. Run your geoserver
cd ./mygeoserver
mvn clean install jetty:run-war -Pjetty.port=2468
open a browser up to http://localhost:2468/geoserver

ALL DONE! Now your geoserver is reading/writing/messing with data in the ./src/main/webapp/data/ dir… and that means you can check that into your scm. It also means you can do filter building on things, multi module projects, staged releases, profile builds… it goes on and on - all good reasons to do this.

<?xml version="1.0" encoding="UTF-8"?> 4.0.0 mygeoserver yourGroupId war 1.0.0-SNAPSHOT mygeoserver Customized geoserver type 'mvn install jetty:run-war -Djetty.port=2468' and goto [http://localhost:2468](http://localhost:2468). org.mortbay.jetty maven-jetty-plugin /geoserver GEOSERVER_DATA_DIR ${basedir}/src/main/webapp/data org.geoserver geoserver 1.6.3 nodata war

On Wed, Apr 16, 2008 at 9:30 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Releasing/Deploying a war to a repository is ‘default’ behaviour of the ‘mvn release:prepare release:perform’ goals - providing the war.

One thing that was an annoying problem is the 30MB release, but we might be able to save 7MB of that by removing ./data. I had a small think about this, and it should be possible to release two instances of the geoserver war. One version as it is now, and another with a classifier=nodata, resulting in geoserver-1.6.0-nodata.war. This can be the dependency that the “standalone/out the box”…
geoserver geoserver 1.6.0 nodata
Anyway, its all talk for now… but food for thought.

–AH

On Tue, Apr 15, 2008 at 10:56 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:
…

Hum, ok, but I don’t know how to push a .war onto a repository… I’m
not even sure we would like to do so. Each .war is 30MB, we’d have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

I would have to say, that this should really only be used with releases
and not SNAPSHOTS, but of course we all like to test.

Very much agreed… thought I have no idea how to make a .war be deployed,
nor how to make an artifact be deployed only during the release… probably
using some profile…

Hum, this sounds like a good candidate for a community module.
Interested in working on it and providing some guidance on how to
use it in the
wiki?

I will try to find some time to see how complex this is in the next couple
of days.

Nice. Looking forward to hear your findings.
Cheers
Andrea

Andrew_Hughes · April 23, 2008, 12:56am

On Wed, Apr 23, 2008 at 10:23 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Ok Guys… Here Goes…

apologies this is off the top of my head and on not on my dev machine to test right now…

Create a copy of geoserver, with an empty data dir. - geoserver “nodata”. (In future this should be in a public repo already)

download geoserver.war (I used v1.6.3)

extract the contents with jar -xvf geoserver.war

take a backup of the /data dir… cp -Rv ./data /tmp/. (you will need this later)

remove the contents of the data dir… rm -rf ./data/*

remove original geoserver.war rm -rf geoserver.war

repack into new war, without data… jar -cvf jar -xvf geoserver-1.6.0-nodata.war *

Install the nodata geoserver in the local maven repo (~/.m2/repository/) (In future this should be in a public repo already)

mvn install:install-file -Dfile=geoserver-1.6.3-nodata.war -DgroupId=org.geoserver -DartifactId=geoserver -Dversion=1.6.3 -Dpackaging=war -Dclassifier=nodata -DgeneratePom=true -DcreateChecksum=true

Create a Maven project that uses the above… and containts geoserver_data_dir contents. (In future this is the only part required by a developer if geoserver-nodata is hosted in a public repo - in fact a customer archetype could fix this too).

mkdir ./mygeoserver

mkdir(s) ./mygeoserver/src/main/webapp/data

cp -Rv /tmp/data/. (this is the backup you took earlier)

should be cp -Rv /tmp/data/* ./src/main/webapp/data/.

create ./mygeoserver/pom.xml (attached below)1. Run your geoserver

cd ./mygeoserver

mvn clean install jetty:run-war -Pjetty.port=2468

open a browser up to http://localhost:2468/geoserver

ALL DONE! Now your geoserver is reading/writing/messing with data in the ./src/main/webapp/data/ dir… and that means you can check that into your scm. It also means you can do filter building on things, multi module projects, staged releases, profile builds… it goes on and on - all good reasons to do this.
<?xml version="1.0" encoding="UTF-8"?> 4.0.0 mygeoserver yourGroupId war 1.0.0-SNAPSHOT mygeoserver Customized geoserver type 'mvn install jetty:run-war -Djetty.port=2468' and goto [http://localhost:2468](http://localhost:2468). org.mortbay.jetty maven-jetty-plugin /geoserver GEOSERVER_DATA_DIR ${basedir}/src/main/webapp/data org.geoserver geoserver 1.6.3 nodata war
On Wed, Apr 16, 2008 at 9:30 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Releasing/Deploying a war to a repository is ‘default’ behaviour of the ‘mvn release:prepare release:perform’ goals - providing the war.

One thing that was an annoying problem is the 30MB release, but we might be able to save 7MB of that by removing ./data. I had a small think about this, and it should be possible to release two instances of the geoserver war. One version as it is now, and another with a classifier=nodata, resulting in geoserver-1.6.0-nodata.war. This can be the dependency that the “standalone/out the box”…
geoserver geoserver 1.6.0 nodata
Anyway, its all talk for now… but food for thought.

–AH

On Tue, Apr 15, 2008 at 10:56 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:
…

Hum, ok, but I don’t know how to push a .war onto a repository… I’m
not even sure we would like to do so. Each .war is 30MB, we’d have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

I would have to say, that this should really only be used with releases
and not SNAPSHOTS, but of course we all like to test.

Very much agreed… thought I have no idea how to make a .war be deployed,
nor how to make an artifact be deployed only during the release… probably
using some profile…

Hum, this sounds like a good candidate for a community module.
Interested in working on it and providing some guidance on how to
use it in the
wiki?

I will try to find some time to see how complex this is in the next couple
of days.

Nice. Looking forward to hear your findings.
Cheers
Andrea

Facundo_Garat · April 23, 2008, 6:00am

Andrew,
i don’t know if i’m on the right path…after this is the problem with deploying as ear in glassfish right?? if so, here are my results until now.

I follow this procedure, everything right. I get Jetty up and running. then i generate an ear from mygeoserver.war and deploy it in glassfish… I get this error instead of the you reported. I have all ready to continue test this.

Any ideas of this error?!..

[#|2008-04-23T02:44:11.118-0300|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=16;_ThreadName=Thread-24;|23 Apr 02:44:11 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘config’ defined in URL [jar:file:/opt/SDK/domains/domain1/applications/j2ee-apps/mygeoserver/mygeoserver-1.0.0-SNAPSHOT_war/WEB-INF/lib/main-1.6.3.jar!/applicationContext.xml]: Initialization of bean failed; nested exception is java.lang.ExceptionInInitializerError: null
java.lang.ExceptionInInitializerError
at org.geotools.gce.geotiff.GeoTiffFormatFactorySpi.createFormat(GeoTiffFormatFactorySpi.java:85)
at org.geotools.coverage.grid.io.GridFormatFinder.getFormatArray(GridFormatFinder.java:148)
at org.vfny.geoserver.util.CoverageStoreUtils.(CoverageStoreUtils.java:46)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverageDTOFromXML(XMLConfigReader.java:1944)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverage(XMLConfigReader.java:1825)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverages(XMLConfigReader.java:1778)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCatalog(XMLConfigReader.java:385)
at org.vfny.geoserver.global.xml.XMLConfigReader.load(XMLConfigReader.java:217)
at org.vfny.geoserver.global.xml.XMLConfigReader.(XMLConfigReader.java:179)
at org.vfny.geoserver.global.Config.setApplicationContext(Config.java:64)
at org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:84)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:248)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:362)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:312)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:318)
at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:134)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:230)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:156)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5184)
at com.sun.enterprise.web.WebModule.start(WebModule.java:326)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222)
at com.sun.enterprise.web.WebContainer.loadJ2EEApplicationWebModules(WebContainer.java:1147)
at com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:141)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
at com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
at com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
at com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
at com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
at com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
at com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:591)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:635)
at com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744)
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:597)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at com.sun.enterprise.deployment.client.DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145)
at com.sun.enterprise.deployment.client.DeployAction.run(DeployAction.java:537)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: vendorName == null!
at javax.imageio.spi.IIOServiceProvider.(IIOServiceProvider.java:59)
at javax.imageio.spi.ImageReaderWriterSpi.(ImageReaderWriterSpi.java:214)
at javax.imageio.spi.ImageReaderSpi.(ImageReaderSpi.java:192)
at com.sun.media.imageioimpl.plugins.tiff.TIFFImageReaderSpi.(TIFFImageReaderSpi.java:73)
at org.geotools.gce.geotiff.GeoTiffFormat.(GeoTiffFormat.java:75)
… 70 more
|#]

On Tue, Apr 22, 2008 at 9:56 PM, Andrew Hughes <ahhughes@anonymised.com> wrote:

On Wed, Apr 23, 2008 at 10:23 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Ok Guys… Here Goes…

apologies this is off the top of my head and on not on my dev machine to test right now…

Create a copy of geoserver, with an empty data dir. - geoserver “nodata”. (In future this should be in a public repo already)

download geoserver.war (I used v1.6.3)

extract the contents with jar -xvf geoserver.war

take a backup of the /data dir… cp -Rv ./data /tmp/. (you will need this later)

remove the contents of the data dir… rm -rf ./data/*

remove original geoserver.war rm -rf geoserver.war

repack into new war, without data… jar -cvf jar -xvf geoserver-1.6.0-nodata.war *

Install the nodata geoserver in the local maven repo (~/.m2/repository/) (In future this should be in a public repo already)

mvn install:install-file -Dfile=geoserver-1.6.3-nodata.war -DgroupId=org.geoserver -DartifactId=geoserver -Dversion=1.6.3 -Dpackaging=war -Dclassifier=nodata -DgeneratePom=true -DcreateChecksum=true

Create a Maven project that uses the above… and containts geoserver_data_dir contents. (In future this is the only part required by a developer if geoserver-nodata is hosted in a public repo - in fact a customer archetype could fix this too).

mkdir ./mygeoserver

mkdir(s) ./mygeoserver/src/main/webapp/data

cp -Rv /tmp/data/. (this is the backup you took earlier)

should be cp -Rv /tmp/data/* ./src/main/webapp/data/.

create ./mygeoserver/pom.xml (attached below)1. Run your geoserver

cd ./mygeoserver

mvn clean install jetty:run-war -Pjetty.port=2468

open a browser up to http://localhost:2468/geoserver

ALL DONE! Now your geoserver is reading/writing/messing with data in the ./src/main/webapp/data/ dir… and that means you can check that into your scm. It also means you can do filter building on things, multi module projects, staged releases, profile builds… it goes on and on - all good reasons to do this.
<?xml version="1.0" encoding="UTF-8"?> 4.0.0 mygeoserver yourGroupId war 1.0.0-SNAPSHOT mygeoserver Customized geoserver type 'mvn install jetty:run-war -Djetty.port=2468' and goto [http://localhost:2468](http://localhost:2468). org.mortbay.jetty maven-jetty-plugin /geoserver GEOSERVER_DATA_DIR ${basedir}/src/main/webapp/data org.geoserver geoserver 1.6.3 nodata war
On Wed, Apr 16, 2008 at 9:30 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Releasing/Deploying a war to a repository is ‘default’ behaviour of the ‘mvn release:prepare release:perform’ goals - providing the war.

One thing that was an annoying problem is the 30MB release, but we might be able to save 7MB of that by removing ./data. I had a small think about this, and it should be possible to release two instances of the geoserver war. One version as it is now, and another with a classifier=nodata, resulting in geoserver-1.6.0-nodata.war. This can be the dependency that the “standalone/out the box”…
geoserver geoserver 1.6.0 nodata
Anyway, its all talk for now… but food for thought.

–AH

On Tue, Apr 15, 2008 at 10:56 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:
…

Hum, ok, but I don’t know how to push a .war onto a repository… I’m
not even sure we would like to do so. Each .war is 30MB, we’d have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

I would have to say, that this should really only be used with releases
and not SNAPSHOTS, but of course we all like to test.

Very much agreed… thought I have no idea how to make a .war be deployed,
nor how to make an artifact be deployed only during the release… probably
using some profile…

Hum, this sounds like a good candidate for a community module.
Interested in working on it and providing some guidance on how to
use it in the
wiki?

I will try to find some time to see how complex this is in the next couple
of days.

Nice. Looking forward to hear your findings.
Cheers
Andrea

This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Facundo Garat Mayer
facundo@anonymised.com

Andrew_Hughes · April 23, 2008, 6:51am

Thanks Facundo,

I avoided mentioning the ear problem on this thread, because it’s really trying to build a working customized war… and it succeeds. The point I was trying to make is that you can suck down geoserver.war with no data, pack in your own data (customize), and you can run it straight out of the maven build process. Being able to run in in the dev environment, means you can use the geoserver web interface, to manipulate the config/data in the ./src/main/webapp/data dir. Hence, you can upload/data/style… eta. Checkin to scm… and build your own spatial geoserver release.

… the next part which I want… is to pack this customized geoserver.war into the same ear as the client application.war(s) that will use and abuse what geoserver has to offer.

What did you think of this approach? Easy/Hard/Worthwhile?

On Wed, Apr 23, 2008 at 3:30 PM, Facundo Garat <facundo.garat@anonymised.com.1330…> wrote:

Andrew,
i don’t know if i’m on the right path…after this is the problem with deploying as ear in glassfish right?? if so, here are my results until now.

I follow this procedure, everything right. I get Jetty up and running. then i generate an ear from mygeoserver.war and deploy it in glassfish… I get this error instead of the you reported. I have all ready to continue test this.

Any ideas of this error?!..

[#|2008-04-23T02:44:11.118-0300|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=16;_ThreadName=Thread-24;|23 Apr 02:44:11 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘config’ defined in URL [jar:file:/opt/SDK/domains/domain1/applications/j2ee-apps/mygeoserver/mygeoserver-1.0.0-SNAPSHOT_war/WEB-INF/lib/main-1.6.3.jar!/applicationContext.xml]: Initialization of bean failed; nested exception is java.lang.ExceptionInInitializerError: null
java.lang.ExceptionInInitializerError
at org.geotools.gce.geotiff.GeoTiffFormatFactorySpi.createFormat(GeoTiffFormatFactorySpi.java:85)
at org.geotools.coverage.grid.io.GridFormatFinder.getFormatArray(GridFormatFinder.java:148)
at org.vfny.geoserver.util.CoverageStoreUtils.(CoverageStoreUtils.java:46)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverageDTOFromXML(XMLConfigReader.java:1944)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverage(XMLConfigReader.java:1825)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverages(XMLConfigReader.java:1778)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCatalog(XMLConfigReader.java:385)
at org.vfny.geoserver.global.xml.XMLConfigReader.load(XMLConfigReader.java:217)
at org.vfny.geoserver.global.xml.XMLConfigReader.(XMLConfigReader.java:179)
at org.vfny.geoserver.global.Config.setApplicationContext(Config.java:64)
at org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:84)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:248)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:362)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:312)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:318)
at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:134)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:230)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:156)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5184)
at com.sun.enterprise.web.WebModule.start(WebModule.java:326)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222)
at com.sun.enterprise.web.WebContainer.loadJ2EEApplicationWebModules(WebContainer.java:1147)
at com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:141)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
at com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
at com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
at com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
at com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
at com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
at com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:591)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:635)
at com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744)
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:597)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at com.sun.enterprise.deployment.client.DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145)
at com.sun.enterprise.deployment.client.DeployAction.run(DeployAction.java:537)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: vendorName == null!
at javax.imageio.spi.IIOServiceProvider.(IIOServiceProvider.java:59)
at javax.imageio.spi.ImageReaderWriterSpi.(ImageReaderWriterSpi.java:214)
at javax.imageio.spi.ImageReaderSpi.(ImageReaderSpi.java:192)
at com.sun.media.imageioimpl.plugins.tiff.TIFFImageReaderSpi.(TIFFImageReaderSpi.java:73)
at org.geotools.gce.geotiff.GeoTiffFormat.(GeoTiffFormat.java:75)
… 70 more
|#]

On Tue, Apr 22, 2008 at 9:56 PM, Andrew Hughes <ahhughes@anonymised.com> wrote:

On Wed, Apr 23, 2008 at 10:23 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Ok Guys… Here Goes…

apologies this is off the top of my head and on not on my dev machine to test right now…

Create a copy of geoserver, with an empty data dir. - geoserver “nodata”. (In future this should be in a public repo already)

download geoserver.war (I used v1.6.3)

extract the contents with jar -xvf geoserver.war

take a backup of the /data dir… cp -Rv ./data /tmp/. (you will need this later)

remove the contents of the data dir… rm -rf ./data/*

remove original geoserver.war rm -rf geoserver.war

repack into new war, without data… jar -cvf jar -xvf geoserver-1.6.0-nodata.war *

Install the nodata geoserver in the local maven repo (~/.m2/repository/) (In future this should be in a public repo already)

mvn install:install-file -Dfile=geoserver-1.6.3-nodata.war -DgroupId=org.geoserver -DartifactId=geoserver -Dversion=1.6.3 -Dpackaging=war -Dclassifier=nodata -DgeneratePom=true -DcreateChecksum=true

Create a Maven project that uses the above… and containts geoserver_data_dir contents. (In future this is the only part required by a developer if geoserver-nodata is hosted in a public repo - in fact a customer archetype could fix this too).

mkdir ./mygeoserver

mkdir(s) ./mygeoserver/src/main/webapp/data

cp -Rv /tmp/data/. (this is the backup you took earlier)

should be cp -Rv /tmp/data/* ./src/main/webapp/data/.

create ./mygeoserver/pom.xml (attached below)1. Run your geoserver

cd ./mygeoserver

mvn clean install jetty:run-war -Pjetty.port=2468

open a browser up to http://localhost:2468/geoserver

ALL DONE! Now your geoserver is reading/writing/messing with data in the ./src/main/webapp/data/ dir… and that means you can check that into your scm. It also means you can do filter building on things, multi module projects, staged releases, profile builds… it goes on and on - all good reasons to do this.
<?xml version="1.0" encoding="UTF-8"?> 4.0.0 mygeoserver yourGroupId war 1.0.0-SNAPSHOT mygeoserver Customized geoserver type 'mvn install jetty:run-war -Djetty.port=2468' and goto [http://localhost:2468](http://localhost:2468). org.mortbay.jetty maven-jetty-plugin /geoserver GEOSERVER_DATA_DIR ${basedir}/src/main/webapp/data org.geoserver geoserver 1.6.3 nodata war
On Wed, Apr 16, 2008 at 9:30 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Releasing/Deploying a war to a repository is ‘default’ behaviour of the ‘mvn release:prepare release:perform’ goals - providing the war.

One thing that was an annoying problem is the 30MB release, but we might be able to save 7MB of that by removing ./data. I had a small think about this, and it should be possible to release two instances of the geoserver war. One version as it is now, and another with a classifier=nodata, resulting in geoserver-1.6.0-nodata.war. This can be the dependency that the “standalone/out the box”…
geoserver geoserver 1.6.0 nodata
Anyway, its all talk for now… but food for thought.

–AH

On Tue, Apr 15, 2008 at 10:56 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:
…

Hum, ok, but I don’t know how to push a .war onto a repository… I’m
not even sure we would like to do so. Each .war is 30MB, we’d have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

I would have to say, that this should really only be used with releases
and not SNAPSHOTS, but of course we all like to test.

Very much agreed… thought I have no idea how to make a .war be deployed,
nor how to make an artifact be deployed only during the release… probably
using some profile…

Hum, this sounds like a good candidate for a community module.
Interested in working on it and providing some guidance on how to
use it in the
wiki?

I will try to find some time to see how complex this is in the next couple
of days.

Nice. Looking forward to hear your findings.
Cheers
Andrea

This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Facundo Garat Mayer
facundo@anonymised.com

Facundo_Garat · April 23, 2008, 2:54pm

it seems easy… scriptable too, so maybe, its possible to create a web tool that allow users to upload the data dir in some format (tar.gz, zip)… and provide customized geoserver download…

the aproach seem very good…

In my case, i download the geoserver.war from the website, unpack it, remove the default data dir and replace it with my own customized data dir and pack it again.

Facundo.-

On Wed, Apr 23, 2008 at 3:51 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Thanks Facundo,

I avoided mentioning the ear problem on this thread, because it’s really trying to build a working customized war… and it succeeds. The point I was trying to make is that you can suck down geoserver.war with no data, pack in your own data (customize), and you can run it straight out of the maven build process. Being able to run in in the dev environment, means you can use the geoserver web interface, to manipulate the config/data in the ./src/main/webapp/data dir. Hence, you can upload/data/style… eta. Checkin to scm… and build your own spatial geoserver release.

… the next part which I want… is to pack this customized geoserver.war into the same ear as the client application.war(s) that will use and abuse what geoserver has to offer.

What did you think of this approach? Easy/Hard/Worthwhile?

On Wed, Apr 23, 2008 at 3:30 PM, Facundo Garat <facundo.garat@anonymised.com> wrote:

Andrew,
i don’t know if i’m on the right path…after this is the problem with deploying as ear in glassfish right?? if so, here are my results until now.

I follow this procedure, everything right. I get Jetty up and running. then i generate an ear from mygeoserver.war and deploy it in glassfish… I get this error instead of the you reported. I have all ready to continue test this.

Any ideas of this error?!..

[#|2008-04-23T02:44:11.118-0300|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=16;_ThreadName=Thread-24;|23 Apr 02:44:11 ERROR [context.ContextLoader] - Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘config’ defined in URL [jar:file:/opt/SDK/domains/domain1/applications/j2ee-apps/mygeoserver/mygeoserver-1.0.0-SNAPSHOT_war/WEB-INF/lib/main-1.6.3.jar!/applicationContext.xml]: Initialization of bean failed; nested exception is java.lang.ExceptionInInitializerError: null
java.lang.ExceptionInInitializerError
at org.geotools.gce.geotiff.GeoTiffFormatFactorySpi.createFormat(GeoTiffFormatFactorySpi.java:85)
at org.geotools.coverage.grid.io.GridFormatFinder.getFormatArray(GridFormatFinder.java:148)
at org.vfny.geoserver.util.CoverageStoreUtils.(CoverageStoreUtils.java:46)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverageDTOFromXML(XMLConfigReader.java:1944)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverage(XMLConfigReader.java:1825)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCoverages(XMLConfigReader.java:1778)
at org.vfny.geoserver.global.xml.XMLConfigReader.loadCatalog(XMLConfigReader.java:385)
at org.vfny.geoserver.global.xml.XMLConfigReader.load(XMLConfigReader.java:217)
at org.vfny.geoserver.global.xml.XMLConfigReader.(XMLConfigReader.java:179)
at org.vfny.geoserver.global.Config.setApplicationContext(Config.java:64)
at org.springframework.context.support.ApplicationContextAwareProcessor.postProcessBeforeInitialization(ApplicationContextAwareProcessor.java:84)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsBeforeInitialization(AbstractAutowireCapableBeanFactory.java:248)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:362)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:312)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:226)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:147)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:275)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:318)
at org.springframework.web.context.support.AbstractRefreshableWebApplicationContext.refresh(AbstractRefreshableWebApplicationContext.java:134)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:230)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:156)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5184)
at com.sun.enterprise.web.WebModule.start(WebModule.java:326)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222)
at com.sun.enterprise.web.WebContainer.loadJ2EEApplicationWebModules(WebContainer.java:1147)
at com.sun.enterprise.server.TomcatApplicationLoader.doLoad(TomcatApplicationLoader.java:141)
at com.sun.enterprise.server.AbstractLoader.load(AbstractLoader.java:244)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:336)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:210)
at com.sun.enterprise.server.ApplicationManager.applicationDeployed(ApplicationManager.java:645)
at com.sun.enterprise.admin.event.AdminEventMulticaster.invokeApplicationDeployEventListener(AdminEventMulticaster.java:928)
at com.sun.enterprise.admin.event.AdminEventMulticaster.handleApplicationDeployEvent(AdminEventMulticaster.java:912)
at com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:461)
at com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176)
at com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308)
at com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226)
at com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298)
at com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132)
at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:591)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.start(PEDeploymentService.java:635)
at com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.start(ApplicationsConfigMBean.java:744)
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:597)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375)
at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358)
at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761)
at sun.reflect.GeneratedMethodAccessor13.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90)
at $Proxy1.invoke(Unknown Source)
at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304)
at com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174)
at com.sun.enterprise.deployment.client.DeploymentClientUtils.startApplication(DeploymentClientUtils.java:145)
at com.sun.enterprise.deployment.client.DeployAction.run(DeployAction.java:537)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalArgumentException: vendorName == null!
at javax.imageio.spi.IIOServiceProvider.(IIOServiceProvider.java:59)
at javax.imageio.spi.ImageReaderWriterSpi.(ImageReaderWriterSpi.java:214)
at javax.imageio.spi.ImageReaderSpi.(ImageReaderSpi.java:192)
at com.sun.media.imageioimpl.plugins.tiff.TIFFImageReaderSpi.(TIFFImageReaderSpi.java:73)
at org.geotools.gce.geotiff.GeoTiffFormat.(GeoTiffFormat.java:75)
… 70 more
|#]

On Tue, Apr 22, 2008 at 9:56 PM, Andrew Hughes <ahhughes@anonymised.com> wrote:

On Wed, Apr 23, 2008 at 10:23 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Ok Guys… Here Goes…

apologies this is off the top of my head and on not on my dev machine to test right now…

Create a copy of geoserver, with an empty data dir. - geoserver “nodata”. (In future this should be in a public repo already)

download geoserver.war (I used v1.6.3)

extract the contents with jar -xvf geoserver.war

take a backup of the /data dir… cp -Rv ./data /tmp/. (you will need this later)

remove the contents of the data dir… rm -rf ./data/*

remove original geoserver.war rm -rf geoserver.war

repack into new war, without data… jar -cvf jar -xvf geoserver-1.6.0-nodata.war *

Install the nodata geoserver in the local maven repo (~/.m2/repository/) (In future this should be in a public repo already)

mvn install:install-file -Dfile=geoserver-1.6.3-nodata.war -DgroupId=org.geoserver -DartifactId=geoserver -Dversion=1.6.3 -Dpackaging=war -Dclassifier=nodata -DgeneratePom=true -DcreateChecksum=true

Create a Maven project that uses the above… and containts geoserver_data_dir contents. (In future this is the only part required by a developer if geoserver-nodata is hosted in a public repo - in fact a customer archetype could fix this too).

mkdir ./mygeoserver

mkdir(s) ./mygeoserver/src/main/webapp/data

cp -Rv /tmp/data/. (this is the backup you took earlier)

should be cp -Rv /tmp/data/* ./src/main/webapp/data/.

create ./mygeoserver/pom.xml (attached below)1. Run your geoserver

cd ./mygeoserver

mvn clean install jetty:run-war -Pjetty.port=2468

open a browser up to http://localhost:2468/geoserver

ALL DONE! Now your geoserver is reading/writing/messing with data in the ./src/main/webapp/data/ dir… and that means you can check that into your scm. It also means you can do filter building on things, multi module projects, staged releases, profile builds… it goes on and on - all good reasons to do this.
<?xml version="1.0" encoding="UTF-8"?> 4.0.0 mygeoserver yourGroupId war 1.0.0-SNAPSHOT mygeoserver Customized geoserver type 'mvn install jetty:run-war -Djetty.port=2468' and goto [http://localhost:2468](http://localhost:2468). org.mortbay.jetty maven-jetty-plugin /geoserver GEOSERVER_DATA_DIR ${basedir}/src/main/webapp/data org.geoserver geoserver 1.6.3 nodata war
On Wed, Apr 16, 2008 at 9:30 AM, Andrew Hughes <ahhughes@anonymised.com> wrote:

Releasing/Deploying a war to a repository is ‘default’ behaviour of the ‘mvn release:prepare release:perform’ goals - providing the war.

One thing that was an annoying problem is the 30MB release, but we might be able to save 7MB of that by removing ./data. I had a small think about this, and it should be possible to release two instances of the geoserver war. One version as it is now, and another with a classifier=nodata, resulting in geoserver-1.6.0-nodata.war. This can be the dependency that the “standalone/out the box”…
geoserver geoserver 1.6.0 nodata
Anyway, its all talk for now… but food for thought.

–AH

On Tue, Apr 15, 2008 at 10:56 PM, Andrea Aime <aaime@anonymised.com> wrote:

Andrew Hughes ha scritto:
…

Hum, ok, but I don’t know how to push a .war onto a repository… I’m
not even sure we would like to do so. Each .war is 30MB, we’d have to
make sure the .war are pushed onto the repo only during the release
process (as opposed to publishing them daily as we for, for instance,
with the geotools jars)

I would have to say, that this should really only be used with releases
and not SNAPSHOTS, but of course we all like to test.

Very much agreed… thought I have no idea how to make a .war be deployed,
nor how to make an artifact be deployed only during the release… probably
using some profile…

Hum, this sounds like a good candidate for a community module.
Interested in working on it and providing some guidance on how to
use it in the
wiki?

I will try to find some time to see how complex this is in the next couple
of days.

Nice. Looking forward to hear your findings.
Cheers
Andrea

This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don’t miss this year’s exciting event. There’s still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Facundo Garat Mayer
facundo@anonymised.com

–

Facundo Garat Mayer
facundo@anonymised.com