Spring doesn't operate so much on the basis of registering things in an
order as looking at the dependencies between bean definitions, then it
comes up with an ordering based on that. To get the desired ordering
requires that all beans declare that they depend on Disposer. The point of
Disposer is to provide something that does work on a 'register for
destruction' basis, so it might well make sense to have it do that
destruction in reverse order of registration.
I'm inclined to go with just making a best effort by having a few major
components depend on it, and then document that anything needing guarantees
about the order of destruction within the spring context beyond that should
be using beans in the spring context rather than Disposer.
On 27 January 2015 at 12:03, Ian Schneider <[email protected]>
wrote:
> As for ordering, it appears that:
>
> "Based on the initialization order of beans, this same order will be
> followed in reverse for consistency."
>
> So registering the Disposer first will ensure it gets called last. If
> relative order is important (as you note, Kevin), components that require
> 'late' disposal can register w/ the Disposer.
>
> On Tue, Jan 27, 2015 at 12:47 PM, Kevin Smith <[email protected]>
> wrote:
>
>> The only mechanism I can see to force ordering of destruction is to make
>> other beans depend on Disposer. Of course anything in a position to mark
>> itself as depending on Disposer doesn't need Disposer as it could just be a
>> DisposableBean itself and then dispose of its resources properly. We could
>> make a few significant components depend on Disposer to try to shunt it
>> down the list a reasonable distance and then document that once destruction
>> starts, registered objects might be destroyed at any time, and if that's
>> not good enough then proper disposal should be used instead.
>>
>> On 27 January 2015 at 00:51, Andrea Aime <[email protected]>
>> wrote:
>>
>>> On Tue, Jan 27, 2015 at 1:33 AM, Kevin Smith <[email protected]>
>>> wrote:
>>>
>>>> Yes, marking the threadpools as Daemon is the really trivial but kludgy
>>>> way of doing it. The Disposer is the nicer but still a bit of a kludge way
>>>> which as the benefit of not leaving the threadpools open after doing an
>>>> undeploy. Making several additional classes Disposable so that they can
>>>> cascade the disposal properly is the really nice and tidy way that involves
>>>> a lot of work, and probably can't be backported.
>>>>
>>>
>>> I did not look in the details, but the assesment of trying to do clean
>>> disposing being hard feels right.
>>>
>>> The Disposer object is indeed a simpler solution, but it might have a
>>> gotcha, what if anything
>>> needs the object being disposed during the shutdown?
>>> Is there any way to make sure the Disposer runs _last_ in the Spring
>>> context shutdown order?
>>> Or anything at the servlet specification level?
>>>
>>> Cheers
>>> Andrea
>>>
>>> --
>>> ==
>>> GeoServer Professional Services from the experts! Visit
>>> http://goo.gl/NWWaa2 for more information.
>>> ==
>>>
>>> Ing. Andrea Aime
>>> @geowolf
>>> Technical Lead
>>>
>>> GeoSolutions S.A.S.
>>> Via Poggio alle Viti 1187
>>> 55054 Massarosa (LU)
>>> Italy
>>> phone: +39 0584 962313
>>> fax: +39 0584 1660272
>>> mob: +39 339 8844549
>>>
>>> http://www.geo-solutions.it
>>> http://twitter.com/geosolutions_it
>>>
>>> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>>>
>>> Le informazioni contenute in questo messaggio di posta elettronica e/o
>>> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
>>> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
>>> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
>>> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
>>> darcene notizia via e-mail e di procedere alla distruzione del messaggio
>>> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
>>> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
>>> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
>>> principi dettati dal D.Lgs. 196/2003.
>>>
>>>
>>>
>>> The information in this message and/or attachments, is intended solely
>>> for the attention and use of the named addressee(s) and may be confidential
>>> or proprietary in nature or covered by the provisions of privacy act
>>> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
>>> Code).Any use not in accord with its purpose, any disclosure, reproduction,
>>> copying, distribution, or either dissemination, either whole or partial, is
>>> strictly forbidden except previous formal approval of the named
>>> addressee(s). If you are not the intended recipient, please contact
>>> immediately the sender by telephone, fax or e-mail and delete the
>>> information in this message that has been received in error. The sender
>>> does not give any warranty or accept liability as the content, accuracy or
>>> completeness of sent messages and accepts no responsibility for changes
>>> made after they were sent or for other risks which arise as a result of
>>> e-mail transmission, viruses, etc.
>>>
>>> -------------------------------------------------------
>>>
>>
>>
>>
>> --
>>
>> Kevin Smith
>>
>> Software Engineer | Boundless <http://boundlessgeo.com/>
>>
>> [email protected]
>>
>> +1-778-785-7459
>>
>> @boundlessgeo <http://twitter.com/boundlessgeo/>
>>
>>
>> <http://twitter.com/boundlessgeo/>
>>
>> [image: http://boundlessgeo.com/]
>> <http://boundlessgeo.com/>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
>
> --
> Ian Schneider
> Software Engineer | Boundless <http://boundlessgeo.com>
> [email protected]
> 1-877-673-6436
> @boundlessgeo <http://twitter.com/boundlessgeo/>
>
>
--
Kevin Smith
Software Engineer | Boundless <http://boundlessgeo.com/>
[email protected]
+1-778-785-7459
@boundlessgeo <http://twitter.com/boundlessgeo/>
<http://twitter.com/boundlessgeo/>
[image: http://boundlessgeo.com/]
<http://boundlessgeo.com/>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
