Hi Chris, thinking about this, I agree in part. It's true that it would be easier if everything was more encapsulated, I think we just have no idea how to get there, or maybe sometimes we do, but it would take more time that we have available.
I'm not totally sold on the "we need everything documented" though, the source code itself is full of examples, I normally just go and see how things were done in other places in the code and mimic what I see. Maybe a starting point for docs would be just pointing out that plenty of examples can be found looking in the source code (e.g., scan the application context files for usages of the same extension point, look for the hierarchy of the extension point) and in tests. An that GeoServer is an atypical Spring application, with lots of historical baggage, which means one should not assume what works for application of recent writing should work for GeoServer, and thus go and see what the existing and working code does instead. Cheers Andrea On Wed, May 8, 2019 at 8:03 PM Chris Hodgson <[email protected]> wrote: > In fairness, it was actually the XML configuration that broke it > (although it happened to be the XML configuration that specified > allowing annotation-drive config). I'm not sure that the problem is > really with where the configuration is, whether it is in an xml or a > class annotation, the problem is that every module needs to be aware of > what all other modules are doing so that they don't step on each other's > toes. It is just a problem inherent to IoC that misbehaving modules can > bring down the whole thing, particularly when there aren't enough > controls in place. In this case, the whole Spring config door is wide > open for a bad module author to abuse. > > In my case, I didn't realize that I was sharing the same spring mvc > configuration as all the other geoserver modules, and I also didn't > realize the entire effect of the spring config directive(s) that I was > using. Then it was all compounded by my erroneous commit to include the > module by default. > > I think the problem of every module needing to be aware of what all > other modules are doing is improved somewhat by using a single XML > config for module over annotations spread throughout the code because it > is fewer places for other module authors to look. However, I think an > even better solution is to reduce the need to be aware of what other > modules are doing at all, with better encapsulation of each modules > functions, and better documentation about what we do need to know about > other modules. In this case it would be handy to know that that > geoserver-rest module was basically replacing the entire spring MVC > configuration system with its own mechanisms. Maybe a list somewhere in > the geoserver docs of all extension points? Maybe I can contribute > something to the docs about this, I see there is a placeholder there now. > > Chris > > On 5/6/2019 9:24 AM, Andrea Aime wrote: > > Also, a bit of a rant if I can, these approaches based on annotations > > look nice when coding them, but one never knows where > > the side effects end up, while with XML hand wiring we get better > > control (see also the mapml module breaking REST completely). > > I guess we should try to discourage using annotations in a project as > > large and complex as GeoServer? > > > > Cheers > > Andrea > > > > > > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.*
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
