In teaching recent developers workshop for GeoServer I indeed take this approach, pointing out "useful" examples after doing my best to explain what parts are in play. -- Jody Garnett
On Thu, 9 May 2019 at 06:12, Andrea Aime <[email protected]> wrote: > 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 >
_______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
