Hi I've been following the discussions the last couple of week(s) and I must admit that it has both been interesting and frustrating. Interesting because I always like to see how different people choose to solve the same or similar problems, frustrating because I (personally) feel that the tone in the emails has been more than once or twice kindof harsh (from all sides if I may call it "sides") and to me sometimes without a reaso...
I would have loved to be more involved in Tamaya or the discussions going on about configuration in general, my excuse (accept it or not :)) is that I work full time, takes care of my company, house and two kids on my own. More on that over a beer or two if we ever meet :) I'm not sure who will be on the meetups but it would be nice / interesting to either listen in / take part of them or at least the result of them. Who knows, I might have some input that will help :) I've been working with Java for 20 years now, mostly as a consultant but also started companies developing products for the financial industry (mostly derivatives trading, post trade systems). I wouldn't call me an expert but I've seen alot of code and done alot of development during the years. Been working as a consultant for banks for a long time now and lately with a customer where I'm involved in developing a "platform" for making it easy for developers to develop bank applications, the platform takes care of (implicitly or explicitly depening on the functionality) all things that a bank applications needs such as audit, security, logging etc. The framework tries to be up to date with JEE and Java (that includes many of the JEE related technologies sich as CDI, JAX-RS, JAX-WS, Bean validation and so on....). Typically a "bank application" is developed by a team and/or maintained by a team of people. In an appserver there can be many "bank applications" running each requiring their configuration. When were going to look at enhancing the way configuration were done we took a look at Tamaya but still decided to write our own (partly inspired by Tamaya) configuration framework. Some of the features we needed I did not find in Tamaya (or maybe I didn't understand how to implement them using Tamaya), we also needed a nice API towards the bank application developers (which ofcourse could have been done on top of Tamaya) but the main reason for rolling our own solution was that we felt it hard to understand how to use Tamaya (maybe due to its flexibility, or maybe the documentation at the early stage of development, I cannot tell exactly what part that made us choose to not use it...). Some of the features we have in our solution are: - API towards the bank application that is annotation based (@ApplicationConfiguration(property=...) and supports different types such as String, Number derivatives and so on (in the configuration it is all string->string) - Bank applications each have their set of configuration properties (META-INF/conf/<application> - Configuration for the platform can be used by bank applications but not overriden by them - All configuration can be set/overriden by operations who are responsible for the servers - Overriding can be done using ordinals, this can also be done withing an application if it contains multiple modules (not all modules might be used for all installations) - Resolving using proprerty placeholder (if needed) syntax within the properites themselves but also withing e.g. XML files read by applications - Properties can be placed in property files under META-INF... an but also in environment entries, system properties, context/jndi etc - The resolving can make use of wether the server is a test server (functional, integration, production test, production), wether its internal or external (different network zones, security mechanisms and so on) and so on.. the configuration can therefor be written once (and only one bank application artifact needs to be built) and used throughout the testing process until (and including) it reaches production - ...and more things... The solution itself is very small but fulfills our needs and is simple to use for the bank application developers. Thanks Regards LF On Tue, Jul 26, 2016 at 11:01 AM, Werner Keil <werner.k...@gmail.com> wrote: > Also seen among many others in CDI where > javax.enterprise.inject.spi.CDIProvider is an SPI element to allow access > to what's the only static accessor in CDI, the class with the same name, > not a static factory itself;-) > > > On Tue, Jul 26, 2016 at 10:36 AM, Werner Keil <werner.k...@gmail.com> > wrote: > > > The name IMO is. A static facade "ConfigurationProvider" is misleading > > because its naming pattern overlaps with SPI elements commonly named > > *Provider everywhere (especially in JSRs, not every other "framework" > > popular or not even makes a distinction between API and SPI;-) > > > > Seems DeltaSpike brought that antipattern into Tamaya since there's at > > least one "provider" package with static facade singletons. If Tamaya can > > live with that, then why not in this Apache PoC. Neither Tamaya nor > > DeltaSpike or Spring will be a 1:1 blueprint for a future standard we > > probably see at least after JavaOne based on what Oracle plans for "Java > EE > > in the Cloud". > > > > Cheers, > > Werner > > > > > > On Tue, Jul 26, 2016 at 8:21 AM, Mark Struberg <strub...@yahoo.de.invalid > > > > wrote: > > > >> That's how it used to be since pretty much almost the beginning. > >> And that part was also not in question imo. > >> > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> > On Thursday, 21 July 2016, 16:02, Anatole Tresch <atsti...@gmail.com> > >> wrote: > >> > > yep... > >> > > >> > 2016-07-21 14:08 GMT+02:00 Werner Keil <werner.k...@gmail.com>: > >> > > >> >> Anatole/all, > >> >> > >> >> So ConfigurationProvider boils down to just a getConfiguration() > >> method > >> >> now? > >> >> > >> >> > >> >> > >> > > > > > -- Med vänlig hälsning / Best regards Lars-Fredrik Smedberg STATEMENT OF CONFIDENTIALITY: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the address(es) and may contain confidential or privileged information. If you are not the intended recipient, please notify Lars-Fredrik Smedberg immediately at itsme...@gmail.com, and destroy all copies of this message and any attachments.
