Re: [Geoserver-devel] Upgrade Jettison dependency version

[Chris Holmes]

Only just seeing this, but a big +1 to versioning our REST API interface.
 It'd be good for people to know what they're working against, and to have
us commit to things being very stable, but have us able to upgrade when we
do want to make changes.

On Mon, Dec 26, 2011 at 1:36 PM, Justin Deoliveira wrote:

> Yeah I like the idea of versioning the rest API since at some point we
> will have to undoubetly make non backward compatible changes. So yeah I
> guess we could call this api version 1 and then if we want to make breaking
> changes on the trunk push it to 2. It would be nice to have at least one
> release of a deprecation cycle though.
>
> On Dec 26, 2011 11:13 AM, "Gabriel Roldan"  wrote:
> >
> > btw, it just occurred to me whether versioning the rest api somehow
> > would be a good thing and feasible.
> > Google's first answer is at
> > <
> http://stackoverflow.com/questions/389169/best-practices-for-api-versioning
> >
> >
> > In an ideal world geoserver version X would support REST api verson Z
> > and Z-1, and there would be a document explaining the api changes
> > between Z and Z-1.
> >
> > Do you think that's something worth pursuing?
> >
> > Cheers,
> > Gabriel
> >
> > On Mon, Dec 26, 2011 at 2:42 PM, Gabriel Roldan 
> wrote:
> > > On Mon, Dec 26, 2011 at 2:01 PM, Justin Deoliveira <
> jdeol...@opengeo.org> wrote:
> > >> Hey gabriel,
> > >>
> > >> Thanks for the detailed explanation. Unfortunately I don't think it
> is an
> > >> option to change the rest API serialization format on the stable
> branch.
> > >> There is just too much code out there written against it. I would be
> OK with
> > >> doing it on the trunk though. Actually this sort of aligns with
> another api
> > >> change I have been thinking about and that is to have then root node
> of an
> > >> object dropped in a collection:
> > >>
> > >> http://xstream.codehaus.org/json-tutorial.html#json-dropping-root
> > >>
> > >> So I guess to upgrade on the stable branch if we upgrade we would
> have to
> > >> tweak converters to maintain the old format. I know it seems a bit
> silly to
> > >> maintain a bug but I think its the safest way forward.
> > >
> > > Yeah I agree on stable it's not an option. Hopefully the rest
> > > collection converter seems to be isolated enough as to make the
> > > backwards compatible change in there, if we had to upgrade jettison on
> > > stable too.
> > > Personally I'm not in a rush, would just need to upgrade jettison when
> > > the time comes to backport the gwc integration improvements. By that
> > > time I'll make sure to propose a patch for review.
> > > Back on to trunk, do you have a timeline for the root element name
> drop?
> > >
> > > Cheers,
> > > Gabriel
> > >
> > >>
> > >> $0.02
> > >>
> > >> -Justin
> > >>
> > >> On Dec 26, 2011 12:00 AM, "Gabriel Roldan" 
> wrote:
> > >>>
> > >>> Due to a bug in Jettison 1.0.1,  serializing and deserializing
> > >>> collections is broken 
> > >>>
> > >>> Here's a test that demonstrates the issue:
> > >>>
> > >>> package org.geoserver.rest.format;
> > >>> ...
> > >>> public class ReflectiveJSONFormatTest extends TestCase {
> > >>>
> > >>>@SuppressWarnings({ "unchecked", "rawtypes" })
> > >>>public void testFoo() throws Exception {
> > >>>
> > >>>ReflectiveJSONFormat format = new ReflectiveJSONFormat();
> > >>>
> > >>>Foo foo = new Foo("list", 2, 3.0, new
> > >>> ArrayList(Arrays.asList(1L, 2.5D)));
> > >>>
> > >>>ByteArrayOutputStream output = new ByteArrayOutputStream();
> > >>>format.write(foo, output);
> > >>>
> > >>>Object read = format.read(new
> > >>> ByteArrayInputStream(output.toByteArray()));
> > >>>
> > >>>assertTrue(read instanceof Foo);
> > >>>Foo foo2 = (Foo) read;
> > >>>assertEquals(foo.getList(), foo2.getList());
> > >>>assertEquals(foo.getProp1(), foo2.getProp1());
> > >>>assertEquals(foo.getProp2(), foo2.getProp2());
> > >>>assertEquals(foo.getProp3(), foo2.getProp3());
> > >>>}
> > >>> }
> > >>>
> > >>> The test fails at the first assert. (Have added a list property to
> the
> > >>> org.geoserver.rest.Foo test object).
> > >>>
> > >>> The generated JSON with the current Jettison version is
> > >>> Jettison 1.0.1:
> > >>>
> > >>>
> {"org.geoserver.rest.Foo":{"list":{"int":[1],"double":2.5},"prop1":"list","prop2":2,"prop3":3}}
> > >>>
> > >>> The generated JSON with Jettison 1.3 (latest release) is:
> > >>> Jettison 1.3:
> > >>>
> > >>>
> {"org.geoserver.rest.Foo":{"list":[{"int":1,"double":2.5}],"prop1":"list","prop2":2,"prop3":3}}
> > >>>
> > >>> As you can see, the currently generated value of the "list" attribute
> > >>> is not a json array as it should be, whilst the Jettison 1.3 one is.
> > >>>
> > >>> Upgrading to Jettison 1.3 breaks some restconfig tests though,
> because
> > >>> they're asserting the "incorrect" format is being generated.
> > >>> For instance:
> > >>> org.geoserver.catalog.

Re: [Geoserver-devel] Hibernate-based catalog LazyInitializationException

[John Armstrong]

On Tue, 24 Jan 2012 15:21:15 -0700, Justin Deoliveira
 wrote:
> And sorry, by disable i mean remove the jars. Or perhaps just the
diskquota
> jar might do it, not 100% sure.
> 
> On Tue, Jan 24, 2012 at 3:20 PM, Justin Deoliveira
> wrote:
> 
>> Hi John,
>>
>> Unfortunately the dbconfig module is sort of unmaintained at the
moment.
>> That said, it looks like gwc is probably doing some initialization in a
>> separate thread, which the hibernate startup does not like.
>>
>> If you don't need geowebcache, i would just disable it for now.
>>
>> -Justin

Thanks; just to be sure I understand you, you think that it's something in
GWC that's conflicting with the Hibernate module?  I'm not sure I
understand where you're getting that, but I'm willing to believe it.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Hibernate-based catalog LazyInitializationException

[Justin Deoliveira]

Hmmm... perhaps some sort of callback interface where code that needs to do
something from a separate thread can do something, and the executor can
ensure that a hibernate session is there.

An alternative would be an different hibernate configuration... like
disabling lazy loading which you pay a performance hit for.

I also believe with spring there is a way to proxy in such a way that
creates sessions on demand etc... to be honest i am a bit ignorant when it
comes to hibernate.

On Tue, Jan 24, 2012 at 4:06 PM, Gabriel Roldan  wrote:

> On Tue, Jan 24, 2012 at 7:33 PM, Justin Deoliveira 
> wrote:
> >
> >
> > On Tue, Jan 24, 2012 at 3:26 PM, John Armstrong  >
> > wrote:
> >>
> >> On Tue, 24 Jan 2012 15:21:15 -0700, Justin Deoliveira
> >>  wrote:
> >> > And sorry, by disable i mean remove the jars. Or perhaps just the
> >> diskquota
> >> > jar might do it, not 100% sure.
> >> >
> >> > On Tue, Jan 24, 2012 at 3:20 PM, Justin Deoliveira
> >> > wrote:
> >> >
> >> >> Hi John,
> >> >>
> >> >> Unfortunately the dbconfig module is sort of unmaintained at the
> >> moment.
> >> >> That said, it looks like gwc is probably doing some initialization
> in a
> >> >> separate thread, which the hibernate startup does not like.
> >> >>
> >> >> If you don't need geowebcache, i would just disable it for now.
> >> >>
> >> >> -Justin
> >>
> >> Thanks; just to be sure I understand you, you think that it's something
> in
> >> GWC that's conflicting with the Hibernate module?  I'm not sure I
> >> understand where you're getting that, but I'm willing to believe it.
> >
> >
> > Sorry, allow me to explain better. The way hibernate is set up in
> geoserver
> > is that a session is bound to a single request, or thread. If you try to
> > access a hibernate backed bean that has a lazy property from outside that
> > thread/session then you get this exception.
> >
> > Now, during regular geoserver operation this is rarely an issue because
> > essentially there is a filter in place that always set ups and tears down
> > the thread local session, meaning that for the life of a single
> > request/thread a valid session will always be present.
> >
> > However, on startup we don't have this same filter available, so we fake
> it.
> > BAsically the code that loads the configuration creates a session before
> > loading, and tears it down after loading. Again this session is bound to
> the
> > current thread, which means if any components that initialize on startup
> do
> > so in a separate thread, and they access a lazy property of a bean, then
> > this exception occurs.
> >
> > So yes, i am saying that gwc is doing just that, it is using a new
> thread to
> > do some of its initialization on startup. Gabriel should be able to
> verify
> > this but i am pretty sure i have run up against this one before.
> >
> > Hope that makes it a bit clearer.
>
> Right. My understanding is that anything that calls the catalog
> outside an http client request will suffer from this. GWC is an
> example, as it may also do that if you want to seed the cache. Another
> example is could think of, but didn't really tried, is the wps module,
> as it can run async processes.
>
> I don't know what the general practice to avoid that kind of lazy
> initialization errors with hibernate is though.
>
> Cheers,
> Gabriel
> >
> > -Justin
> >
> > --
> > Justin Deoliveira
> > OpenGeo - http://opengeo.org
> > Enterprise support for open source geospatial.
> >
>
>
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Upgrade Jettison dependency version

[Gabriel Roldan]

On Tue, Jan 24, 2012 at 7:28 PM, Justin Deoliveira  wrote:
>
>
> On Tue, Jan 24, 2012 at 1:25 PM, Gabriel Roldan  wrote:
>>
>> Resurrecting this old thread a bit...
>>
>> On Mon, Dec 26, 2011 at 3:36 PM, Justin Deoliveira 
>> wrote:
>> > Yeah I like the idea of versioning the rest API since at some point we
>> > will
>> > have to undoubetly make non backward compatible changes. So yeah I guess
>> > we
>> > could call this api version 1 and then if we want to make breaking
>> > changes
>> > on the trunk push it to 2. It would be nice to have at least one release
>> > of
>> > a deprecation cycle though.
>> Yeah, by versioning the REST API I mean if GeoServer release N
>> supports rest api version M, GeoServer N+1 should support at least
>> rest api M _and_ M+1.
>> Is that what you mean?
>
>
> Yes, more or less.
>>
>>
>> Back to the original topic, if I wanted to upgrade the Jettison
>> version on trunk, would we also need a patch that preserves the old
>> collections encoding behavior, or would you be up to "fixing" it right
>> now?
>
>
> Well this is not set in stone but I think we should first "deprecate" the
> old structure in a stable release.  So yes on trunk I would like to see the
> upgrade happen with a patch that preserves the old structure via a flag that
> is enabled by default.

yeah, that's what I thought as well. Cool then, will make sure to
provide a patch that preserves the current encoding.

Cheers,
Gabriel
>
> In the documentation we should deprecate the old collection representations
> as well.
>
> -Justin
>>

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Hibernate-based catalog LazyInitializationException

[Gabriel Roldan]

On Tue, Jan 24, 2012 at 7:33 PM, Justin Deoliveira  wrote:
>
>
> On Tue, Jan 24, 2012 at 3:26 PM, John Armstrong 
> wrote:
>>
>> On Tue, 24 Jan 2012 15:21:15 -0700, Justin Deoliveira
>>  wrote:
>> > And sorry, by disable i mean remove the jars. Or perhaps just the
>> diskquota
>> > jar might do it, not 100% sure.
>> >
>> > On Tue, Jan 24, 2012 at 3:20 PM, Justin Deoliveira
>> > wrote:
>> >
>> >> Hi John,
>> >>
>> >> Unfortunately the dbconfig module is sort of unmaintained at the
>> moment.
>> >> That said, it looks like gwc is probably doing some initialization in a
>> >> separate thread, which the hibernate startup does not like.
>> >>
>> >> If you don't need geowebcache, i would just disable it for now.
>> >>
>> >> -Justin
>>
>> Thanks; just to be sure I understand you, you think that it's something in
>> GWC that's conflicting with the Hibernate module?  I'm not sure I
>> understand where you're getting that, but I'm willing to believe it.
>
>
> Sorry, allow me to explain better. The way hibernate is set up in geoserver
> is that a session is bound to a single request, or thread. If you try to
> access a hibernate backed bean that has a lazy property from outside that
> thread/session then you get this exception.
>
> Now, during regular geoserver operation this is rarely an issue because
> essentially there is a filter in place that always set ups and tears down
> the thread local session, meaning that for the life of a single
> request/thread a valid session will always be present.
>
> However, on startup we don't have this same filter available, so we fake it.
> BAsically the code that loads the configuration creates a session before
> loading, and tears it down after loading. Again this session is bound to the
> current thread, which means if any components that initialize on startup do
> so in a separate thread, and they access a lazy property of a bean, then
> this exception occurs.
>
> So yes, i am saying that gwc is doing just that, it is using a new thread to
> do some of its initialization on startup. Gabriel should be able to verify
> this but i am pretty sure i have run up against this one before.
>
> Hope that makes it a bit clearer.

Right. My understanding is that anything that calls the catalog
outside an http client request will suffer from this. GWC is an
example, as it may also do that if you want to seed the cache. Another
example is could think of, but didn't really tried, is the wps module,
as it can run async processes.

I don't know what the general practice to avoid that kind of lazy
initialization errors with hibernate is though.

Cheers,
Gabriel
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>



-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] wfs-ng

[Gabriel Roldan]

On Tue, Jan 24, 2012 at 7:41 PM, Justin Deoliveira  wrote:
> On Tue, Jan 24, 2012 at 1:56 PM, Gabriel Roldan  wrote:
>>
>> Hi all,
>>
>> I'll be working on the wfs-ng module this and next weeks with the
>> following high level goals:
>> - port to ContentDataStore
>> - have a single WFSDataStore implementation with strategy objects for
>> the different versions, instead of one datastore per wfs version
>> - make it share the http client code with the wms and wps modules
>> - implement transaction support for wfs .1.1
>> - verify interoperability with a bunch of customer provided wfs instances
>>
>> Just ran into the question of what the earlier approach for "ng"
>> modules was before they're ready to replace the "original" ones, in
>> terms of connection parameter clashes.
>> Do we prefer "ng" modules:
>> 1- to share the connection parameter names with the old ones, so that
>> they can be easily replaced
>
>
>
>> 2- to temporarily use some different parameter name so that both
>> original and ng can be used at the same time, but fall back to the
>> original connection parameter when it's ready to replace the old
>> module
>>
>> 3- just use a different set of parameter names
>
>
> The jdbc case was a bit different because of the "dbtype" parameter, which
> was really what did the matching of parameters to factory implementations.
> But I don't think wfs has the equivalent. ANyways, postgis for example,
> during the deprecation phase of the old datastore tried not to interfere, by
> only accepting "postgis-ng" as the dbtype. Once the old datastore was moved
> to unsupported only then did the new factory take over and start to accept
> "postgis".

Thanks Justin, that makes sense. So I'll follow that approach, letting
them coexist until ng can replace, then it can take over the original
parameter set.

>
> I suggest following a similar approach, which I think this your #2.
>>
>>
>> Additionally, it just occurred to me that the datastore could be
>> configured to use both a pooling http client (as the wms client can)
>> and to fetch features from the upstream server using multiple threads.
>> Default behavior would be to use a single thread. The old wfs 1.0
>> client forced spawning a new fetching thread per request, which didn't
>> scale, so we had to avoid that. I'm thinking a more modern approach
>> could be taken though, in order to have a fixed number of threads that
>> hit a given wfs server, and still get some performance improvement by
>> allowing a single request to use multiple threads to fetch contents,
>> as long as the upstream server supports paging. I'm not committed yet
>> to do that,but feedback would be much appreciated.
>
>
> Makes sense... WFS is exactly built for speed as a protocol so i imagine
> that threads will spend a lot of time waiting on I/O anyways... an
> asynchronous approach probably makes more sense.

yup, lets see if something good comes out of it. I'm sure there's a
lot of good literature on how to do that well. Anyways, not a
requirement, just on the wish list.

Cheers,
Gabriel

>>
>>
>> TIA,
>> Gabriel.
>>
>> --
>> Gabriel Roldan
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>>
>>
>> --
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> ___
>> Geoserver-devel mailing list
>> Geoserver-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>



-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] wfs-ng

[Justin Deoliveira]

On Tue, Jan 24, 2012 at 1:56 PM, Gabriel Roldan  wrote:

> Hi all,
>
> I'll be working on the wfs-ng module this and next weeks with the
> following high level goals:
> - port to ContentDataStore
> - have a single WFSDataStore implementation with strategy objects for
> the different versions, instead of one datastore per wfs version
> - make it share the http client code with the wms and wps modules
> - implement transaction support for wfs .1.1
> - verify interoperability with a bunch of customer provided wfs instances
>
> Just ran into the question of what the earlier approach for "ng"
> modules was before they're ready to replace the "original" ones, in
> terms of connection parameter clashes.
> Do we prefer "ng" modules:
> 1- to share the connection parameter names with the old ones, so that
> they can be easily replaced
>


2- to temporarily use some different parameter name so that both
> original and ng can be used at the same time, but fall back to the
> original connection parameter when it's ready to replace the old
> module

3- just use a different set of parameter names
>

The jdbc case was a bit different because of the "dbtype" parameter, which
was really what did the matching of parameters to factory implementations.
But I don't think wfs has the equivalent. ANyways, postgis for example,
during the deprecation phase of the old datastore tried not to interfere,
by only accepting "postgis-ng" as the dbtype. Once the old datastore was
moved to unsupported only then did the new factory take over and start to
accept "postgis".

I suggest following a similar approach, which I think this your #2.

>
> Additionally, it just occurred to me that the datastore could be
> configured to use both a pooling http client (as the wms client can)
> and to fetch features from the upstream server using multiple threads.
> Default behavior would be to use a single thread. The old wfs 1.0
> client forced spawning a new fetching thread per request, which didn't
> scale, so we had to avoid that. I'm thinking a more modern approach
> could be taken though, in order to have a fixed number of threads that
> hit a given wfs server, and still get some performance improvement by
> allowing a single request to use multiple threads to fetch contents,
> as long as the upstream server supports paging. I'm not committed yet
> to do that,but feedback would be much appreciated.
>

Makes sense... WFS is exactly built for speed as a protocol so i imagine
that threads will spend a lot of time waiting on I/O anyways... an
asynchronous approach probably makes more sense.

>
> TIA,
> Gabriel.
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
>
> --
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> ___
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Hibernate-based catalog LazyInitializationException

[Justin Deoliveira]

On Tue, Jan 24, 2012 at 3:26 PM, John Armstrong wrote:

> On Tue, 24 Jan 2012 15:21:15 -0700, Justin Deoliveira
>  wrote:
> > And sorry, by disable i mean remove the jars. Or perhaps just the
> diskquota
> > jar might do it, not 100% sure.
> >
> > On Tue, Jan 24, 2012 at 3:20 PM, Justin Deoliveira
> > wrote:
> >
> >> Hi John,
> >>
> >> Unfortunately the dbconfig module is sort of unmaintained at the
> moment.
> >> That said, it looks like gwc is probably doing some initialization in a
> >> separate thread, which the hibernate startup does not like.
> >>
> >> If you don't need geowebcache, i would just disable it for now.
> >>
> >> -Justin
>
> Thanks; just to be sure I understand you, you think that it's something in
> GWC that's conflicting with the Hibernate module?  I'm not sure I
> understand where you're getting that, but I'm willing to believe it.
>

Sorry, allow me to explain better. The way hibernate is set up in geoserver
is that a session is bound to a single request, or thread. If you try to
access a hibernate backed bean that has a lazy property from outside that
thread/session then you get this exception.

Now, during regular geoserver operation this is rarely an issue because
essentially there is a filter in place that always set ups and tears down
the thread local session, meaning that for the life of a single
request/thread a valid session will always be present.

However, on startup we don't have this same filter available, so we fake
it. BAsically the code that loads the configuration creates a session
before loading, and tears it down after loading. Again this session is
bound to the current thread, which means if any components that initialize
on startup do so in a separate thread, and they access a lazy property of a
bean, then this exception occurs.

So yes, i am saying that gwc is doing just that, it is using a new thread
to do some of its initialization on startup. Gabriel should be able to
verify this but i am pretty sure i have run up against this one before.

Hope that makes it a bit clearer.

-Justin

-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Upgrade Jettison dependency version

[Justin Deoliveira]

On Tue, Jan 24, 2012 at 1:25 PM, Gabriel Roldan  wrote:

> Resurrecting this old thread a bit...
>
> On Mon, Dec 26, 2011 at 3:36 PM, Justin Deoliveira 
> wrote:
> > Yeah I like the idea of versioning the rest API since at some point we
> will
> > have to undoubetly make non backward compatible changes. So yeah I guess
> we
> > could call this api version 1 and then if we want to make breaking
> changes
> > on the trunk push it to 2. It would be nice to have at least one release
> of
> > a deprecation cycle though.
> Yeah, by versioning the REST API I mean if GeoServer release N
> supports rest api version M, GeoServer N+1 should support at least
> rest api M _and_ M+1.
> Is that what you mean?
>

Yes, more or less.

>
> Back to the original topic, if I wanted to upgrade the Jettison
> version on trunk, would we also need a patch that preserves the old
> collections encoding behavior, or would you be up to "fixing" it right
> now?
>

Well this is not set in stone but I think we should first "deprecate" the
old structure in a stable release.  So yes on trunk I would like to see the
upgrade happen with a patch that preserves the old structure via a flag
that is enabled by default.

In the documentation we should deprecate the old collection representations
as well.

-Justin

>
> Cheers,
> Gabriel
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Hibernate-based catalog LazyInitializationException

[Justin Deoliveira]

And sorry, by disable i mean remove the jars. Or perhaps just the diskquota
jar might do it, not 100% sure.

On Tue, Jan 24, 2012 at 3:20 PM, Justin Deoliveira wrote:

> Hi John,
>
> Unfortunately the dbconfig module is sort of unmaintained at the moment.
> That said, it looks like gwc is probably doing some initialization in a
> separate thread, which the hibernate startup does not like.
>
> If you don't need geowebcache, i would just disable it for now.
>
> -Justin
>
>
> On Tue, Jan 24, 2012 at 11:09 AM, John Armstrong 
> wrote:
>
>> Hi, all.
>>
>> I'm trying to set up the hibernate-based catalog in GeoServer.  I can't
>> seem to get the war to build on its own, so I grabbed the latest from
>> (http://gridlock.opengeo.org/geoserver/2.1.x/), along with the compiled
>> dbconfig plugin from
>> (http://gridlock.opengeo.org/geoserver/2.1.x/community-latest/).  After
>> adding the dbconfig jars (and an antlr jar for an exception class that
>> seemed to be missing) I try deploying the war to Tomcat.  I keep getting a
>> LazyInitializationException (stack trace at the end) at this point.
>>
>> Is there some other initialization/setup step I'm missing?
>>
>> I don't know if this is related: I see this page
>> (geoserver-us...@lists.sourceforge.net) that says the database is stored
>> in
>> geoserver.db, but in my geoserver data directory I see instead
>>
>> geoserver.1.log.db
>> geoserver.data.db
>> geoserver.index.db
>>
>> Thanks in advance for any help you can offer.
>>
>> Stack Trace
>> ---
>> 24 Jan 11:39:58 ERROR [context.ContextLoader] - Context initialization
>> failed
>> org.springframework.beans.factory.BeanCreationException: Error creating
>> bean with name 'gwcFacade' defined in URL
>>
>> [jar:file:/opt/devel/tools/apache-tomcat-7.0.12/webapps/geoserver/WEB-INF/lib/gwc-2.1-SNAPSHOT.jar!/geowebcache-geoserver-context.xml]:
>> Cannot resolve reference to bean 'DiskQuotaStore' while setting
>> constructor argument; nested exception is
>> org.springframework.beans.factory.BeanCreationException: Error creating
>> bean with name 'DiskQuotaStore' defined in URL
>>
>> [jar:file:/opt/devel/tools/apache-tomcat-7.0.12/webapps/geoserver/WEB-INF/lib/gwc-2.1-SNAPSHOT.jar!/geowebcache-diskquota-context.xml]:
>> Invocation of init method failed; nested exception is
>> org.hibernate.LazyInitializationException: could not initialize proxy - no
>> Session
>>at
>>
>> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:275)
>>at
>>
>> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:104)
>>at
>>
>> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:495)
>>at
>>
>> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:162)
>>at
>>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
>>at
>>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:835)
>>at
>>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
>>at
>>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
>>at java.security.AccessController.doPrivileged(Native Method)
>>at
>>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
>>at
>>
>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
>>at
>>
>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
>>at
>>
>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
>>at
>>
>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
>>at
>>
>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
>>at
>>
>> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
>>at
>>
>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
>>at
>>
>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381)
>>at
>>
>> org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
>>at
>>
>> org.sprin

Re: [Geoserver-devel] Hibernate-based catalog LazyInitializationException

[Justin Deoliveira]

Hi John,

Unfortunately the dbconfig module is sort of unmaintained at the moment.
That said, it looks like gwc is probably doing some initialization in a
separate thread, which the hibernate startup does not like.

If you don't need geowebcache, i would just disable it for now.

-Justin

On Tue, Jan 24, 2012 at 11:09 AM, John Armstrong wrote:

> Hi, all.
>
> I'm trying to set up the hibernate-based catalog in GeoServer.  I can't
> seem to get the war to build on its own, so I grabbed the latest from
> (http://gridlock.opengeo.org/geoserver/2.1.x/), along with the compiled
> dbconfig plugin from
> (http://gridlock.opengeo.org/geoserver/2.1.x/community-latest/).  After
> adding the dbconfig jars (and an antlr jar for an exception class that
> seemed to be missing) I try deploying the war to Tomcat.  I keep getting a
> LazyInitializationException (stack trace at the end) at this point.
>
> Is there some other initialization/setup step I'm missing?
>
> I don't know if this is related: I see this page
> (geoserver-us...@lists.sourceforge.net) that says the database is stored
> in
> geoserver.db, but in my geoserver data directory I see instead
>
> geoserver.1.log.db
> geoserver.data.db
> geoserver.index.db
>
> Thanks in advance for any help you can offer.
>
> Stack Trace
> ---
> 24 Jan 11:39:58 ERROR [context.ContextLoader] - Context initialization
> failed
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'gwcFacade' defined in URL
>
> [jar:file:/opt/devel/tools/apache-tomcat-7.0.12/webapps/geoserver/WEB-INF/lib/gwc-2.1-SNAPSHOT.jar!/geowebcache-geoserver-context.xml]:
> Cannot resolve reference to bean 'DiskQuotaStore' while setting
> constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'DiskQuotaStore' defined in URL
>
> [jar:file:/opt/devel/tools/apache-tomcat-7.0.12/webapps/geoserver/WEB-INF/lib/gwc-2.1-SNAPSHOT.jar!/geowebcache-diskquota-context.xml]:
> Invocation of init method failed; nested exception is
> org.hibernate.LazyInitializationException: could not initialize proxy - no
> Session
>at
>
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:275)
>at
>
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:104)
>at
>
> org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:495)
>at
>
> org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:162)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:835)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
>at java.security.AccessController.doPrivileged(Native Method)
>at
>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
>at
>
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
>at
>
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
>at
>
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
>at
>
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
>at
>
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
>at
>
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
>at
>
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
>at
>
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381)
>at
>
> org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
>at
>
> org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
>at
>
> org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
>at
>
> org.geoserver.platform.GeoServerContextLoaderListener.contextInitial

[Geoserver-devel] wfs-ng

[Gabriel Roldan]

Hi all,

I'll be working on the wfs-ng module this and next weeks with the
following high level goals:
- port to ContentDataStore
- have a single WFSDataStore implementation with strategy objects for
the different versions, instead of one datastore per wfs version
- make it share the http client code with the wms and wps modules
- implement transaction support for wfs .1.1
- verify interoperability with a bunch of customer provided wfs instances

Just ran into the question of what the earlier approach for "ng"
modules was before they're ready to replace the "original" ones, in
terms of connection parameter clashes.
Do we prefer "ng" modules:
1- to share the connection parameter names with the old ones, so that
they can be easily replaced
2- to temporarily use some different parameter name so that both
original and ng can be used at the same time, but fall back to the
original connection parameter when it's ready to replace the old
module
3- just use a different set of parameter names

Additionally, it just occurred to me that the datastore could be
configured to use both a pooling http client (as the wms client can)
and to fetch features from the upstream server using multiple threads.
Default behavior would be to use a single thread. The old wfs 1.0
client forced spawning a new fetching thread per request, which didn't
scale, so we had to avoid that. I'm thinking a more modern approach
could be taken though, in order to have a fixed number of threads that
hit a given wfs server, and still get some performance improvement by
allowing a single request to use multiple threads to fetch contents,
as long as the upstream server supports paging. I'm not committed yet
to do that,but feedback would be much appreciated.

TIA,
Gabriel.

-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] Upgrade Jettison dependency version

[Gabriel Roldan]

Resurrecting this old thread a bit...

On Mon, Dec 26, 2011 at 3:36 PM, Justin Deoliveira  wrote:
> Yeah I like the idea of versioning the rest API since at some point we will
> have to undoubetly make non backward compatible changes. So yeah I guess we
> could call this api version 1 and then if we want to make breaking changes
> on the trunk push it to 2. It would be nice to have at least one release of
> a deprecation cycle though.
Yeah, by versioning the REST API I mean if GeoServer release N
supports rest api version M, GeoServer N+1 should support at least
rest api M _and_ M+1.
Is that what you mean?

Back to the original topic, if I wanted to upgrade the Jettison
version on trunk, would we also need a patch that preserves the old
collections encoding behavior, or would you be up to "fixing" it right
now?

Cheers,
Gabriel

-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Hibernate-based catalog LazyInitializationException

[John Armstrong]

Hi, all.

I'm trying to set up the hibernate-based catalog in GeoServer.  I can't
seem to get the war to build on its own, so I grabbed the latest from
(http://gridlock.opengeo.org/geoserver/2.1.x/), along with the compiled
dbconfig plugin from
(http://gridlock.opengeo.org/geoserver/2.1.x/community-latest/).  After
adding the dbconfig jars (and an antlr jar for an exception class that
seemed to be missing) I try deploying the war to Tomcat.  I keep getting a
LazyInitializationException (stack trace at the end) at this point.

Is there some other initialization/setup step I'm missing?

I don't know if this is related: I see this page
(geoserver-us...@lists.sourceforge.net) that says the database is stored in
geoserver.db, but in my geoserver data directory I see instead

geoserver.1.log.db
geoserver.data.db
geoserver.index.db

Thanks in advance for any help you can offer.

Stack Trace
---
24 Jan 11:39:58 ERROR [context.ContextLoader] - Context initialization
failed
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'gwcFacade' defined in URL
[jar:file:/opt/devel/tools/apache-tomcat-7.0.12/webapps/geoserver/WEB-INF/lib/gwc-2.1-SNAPSHOT.jar!/geowebcache-geoserver-context.xml]:
Cannot resolve reference to bean 'DiskQuotaStore' while setting
constructor argument; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'DiskQuotaStore' defined in URL
[jar:file:/opt/devel/tools/apache-tomcat-7.0.12/webapps/geoserver/WEB-INF/lib/gwc-2.1-SNAPSHOT.jar!/geowebcache-diskquota-context.xml]:
Invocation of init method failed; nested exception is
org.hibernate.LazyInitializationException: could not initialize proxy - no
Session
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:275)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:104)
at
org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:495)
at
org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:162)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:925)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:835)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:440)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:221)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:729)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:381)
at
org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
at
org.geoserver.platform.GeoServerContextLoaderListener.contextInitialized(GeoServerContextLoaderListener.java:18)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4701)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5204)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5199)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadP

Re: [Geoserver-devel] [Live-demo] OpenJDK Only for LiveDVD 5.5?

[Even Rouault]

Le dimanche 01 janvier 2012 19:03:33, Andrea Aime a écrit :
> On Sun, Jan 1, 2012 at 6:55 PM, Andrea Aime wrote:
> > The brief facts:
> >> * Sun Java is not allowed to be packaged into future distributions (like
> >> ubuntu, debian, or OSGeo-Live). Instead, users are expected to download
> >> SunJava from Sun.
> >> * SunJava 7 will be based upon OpenJDK.
> >> * OpenJDK is reportedly much better than previous OpenJDK versions.
> 
> Hmmm I wanted to run a benchmark to substantiate this claim but there
> are no OpenJDK 7 binaries available
> for my aging Ubuntu 10.04 (which I'll upgrade only when the new LTS shows
> up).
> 
> Also, on Windows there are no OpenJDK builds so in the end we need to
> target Oracle JDK anyways (besides
> the obvious business reasons), this means a OpenJDK support will have to
> come in parallel (aka "more work")

Not sure how/if it can help for geoserver/geotools, but I can give you some of 
my experience with OpenJDK6 and Windows. I have ported a quite big Java app 
from Sun Java 1.4.2 -> Sun Java 1.6.0 -> OpenJDK 1.6.0 and it is now in 
production in our client.

It is true that there are no Windows OpenJDK builds easily found. I finally 
build mine. The hardest part was to gather all the requirements (cygwin, 
directx headers, freetype, GNU make, etc...), plus some undocumented issues 
that I finally identified as being due to my use of a non-English version of 
MSVC. But overall I found that the build instructions worked well if you 
follow them closely. Lately, I've updated to the build b23 and found that the 
building process was a bit easier than during my first experience that dated 
back to more than 1 year 1/2.

As far as the port of the app is concerned, most problems found were due to an 
inadequate use of some bits of the Java API where the Sun Java 1.4.2/1.6 
implementation were permissive, but the OpenJDK one not. When looking at the 
docs, we realized that we were relying on unspecified behaviour. The most 
problematic was due to an inadequate use of threading with AWT (use of AWT 
from another thread than the AWT event dispatch thread).

The other most problematic part I can recall was related to font rendering. 
The font engine of the windows openjdk build uses freetype whereas the 
commercial version uses a closed-source engine. This required adjusting font 
sizes in GUIs and setting some anti-aliasing hints.

I'm not sure if the changes we did would have been necessary if we had 
targetted JDK7/OpenJDK7 directly instead of OpenJDK6, but at the time they 
were done it wasn't yet released.

Best regards,

Even

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] asking for feedback on gwc integration improvements

[Gabriel Roldan]

Hello all,

I'd like to ask for your opinions on a number of GWC integration
improvements, as a continuation of the earlier work presented a couple
weeks ago, for which I'm copying the screenshots bellow.
These are the final bits for the long standing work described at
http://jira.codehaus.org/browse/GEOS-4460

The goal is to make the integrated gwc configuration much easier,
allowing to configure both gridsets and cached layers through the UI.

But besides what can be inferred from the screenshots, I wanted to
gather some feedback on the following issues:
- When we stopped faking a gwc's WMSLayer per GeoServer layer/group,
we started storing the geoserver's tile layer configuration options in
each Layer(Group)Info's metadata map, as a set of properties
(GWC.enabled, GWC.gutter, GWC.gridsets, etc). Now, while enabling to
configure almost every aspect of the cached layer, instead of storing
a single metadata entry for each cached layer property, I'd rather
store the whole tile layer configuration as a single metadata entry,
in its JSON representation. Earlier experience in doing that is the
storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
LayerGroupInfo metadata map, and it seems to be working well. So if
there's no opposition I'd store the tile layer configuration as a
single JSON entry in the metadata map, allowing for the natural
evolution of the cached layer configuration without extra bloating of
the metadata map (backwards compatible with the current set of
entries, of course).

- The other things I'd like to gather feedback about are related to the UI.
* To start with, I got some feedback on that the "Cached Layers" menu
entry on the "Data" menu is kind of awkward/confusing. As background
information, the only reason for that page to exist instead of being
integrated directly with the regular "Layers" page is that GWC
supports also externally configured tile layers, which wouldn't fit on
the layers/layergroup pages. So the proposal is to get rid of that
menu entry, and instead integrate the list of cached layers (both
geoserver's and external) as a tab in the "GeoWebCache" configuration
page.

* Rename the "GeoWebCache" menu entry in the settings menu. Looks like
people need to know what "GeoWebCache" is. It'd be better to call that
menu entry something more related to what it does, like "Tile Cache"
or something like that. Suggestions welcomed.

* Make the LayerGroup edit page tabbed. It's getting messy
.
It'd be better if it had tabs just like the Layer/Resource edit page,
so that tile caching has it's own tab:


TIA for all and any feedback,
Gabriel.













-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Geoserver-devel] Call for vote on GSIP 68 - Introduce GUAVA library as dependency

[Gabriel Roldan]

Hi all,
Thanks all for the opinions and early voting expressed about GSIP 68 -
Introduce GUAVA library as dependency.

I would like to call for formal voting final vote and move the
proposal forward this week, at least there's something else to
discuss. Either will be much appreciated.

The early vote count is:
Justin: +0
Ben: +0
Andrea: +1
Jody: +1
Gabriel +1

Would you please confirm/update the wiki page, or raise any remaining
concern that needs to be discussed?

TIA,
Gabriel
-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] JDBC session startup and teardown in GeoServer

[Andrea Aime]

On Tue, Jan 24, 2012 at 11:49 AM, Andrea Aime
wrote:

> On Tue, Jan 3, 2012 at 4:56 PM, Chris Holmes  wrote:
>
>> Sounds awesome.  I've definitely heard a user desire for this - it's
>> particularly important for 'big enterprise' style users.  And the generic
>> approach here sounds really nice.
>>
>> Key to getting this widely used seems to be good docs on the most common
>> case.  So I hope you guys have the time to document it decently, but of
>> course if you don't have the time it shouldn't be a blocker at all, will be
>> great to have the functionality there.
>>
>
> For those that are interested, the work has been committed on both
> GeoTools and GeoServer,
> and I've rolled out a documentation page for it here:
>
>
> http://docs.geoserver.org/latest/en/user/data/data/images/postgresqlSession.png
>

Ah hem, wrong link, here is the good one:

http://docs.geoserver.org/latest/en/user/data/sqlsession.html

Cheers
Andrea


-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:+39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Re: [Geoserver-devel] JDBC session startup and teardown in GeoServer

[Andrea Aime]

On Tue, Jan 3, 2012 at 4:56 PM, Chris Holmes  wrote:

> Sounds awesome.  I've definitely heard a user desire for this - it's
> particularly important for 'big enterprise' style users.  And the generic
> approach here sounds really nice.
>
> Key to getting this widely used seems to be good docs on the most common
> case.  So I hope you guys have the time to document it decently, but of
> course if you don't have the time it shouldn't be a blocker at all, will be
> great to have the functionality there.
>

For those that are interested, the work has been committed on both GeoTools
and GeoServer,
and I've rolled out a documentation page for it here:

http://docs.geoserver.org/latest/en/user/data/data/images/postgresqlSession.png

Cheers
Andrea

-- 
---
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:  +39 0584 962313
mob:+39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

---
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel