probably have 2 ways as already explained: 1.) a single ConfigSource with an URL parameter 2.) a classpath resource name -> register multiple ConfigSources.
That will probably solve 98% of all cases. And this is really easy to do and perfectly portable as well. LieGrue, strub > On Sunday, 11 January 2015, 18:07, Romain Manni-Bucau <[email protected]> > wrote: > > What's your base use case? why not classpath: -> > loader.getResources(path)? Do you need something else than an > inputstream? > > Side note: we already said you the only way to solve it is to allow > user to extend your code base which is surely overcomplicated but > tamaya needs IMO. > > > 2015-01-11 18:01 GMT+01:00 Anatole Tresch <[email protected]>: >> Basically I dont care. Instead of listing me how bloated things are, start >> discussing how it can be solved. I have a crucial use case here, that must >> be solved. I have a solution that many users are satisifed with and which >> works well in SE as well as in Weblogic (Credit Suisse). Either make a >> proposal how things can be improved or live with what we have IMO. >> >> 2015-01-11 17:57 GMT+01:00 Anatole Tresch <[email protected]>: >> >>> Basically I dont care. Instead of listing me how bloated things are, > start >>> discussing how it can be solved. I have a crucial use case here, that > must >>> be solved. I have a solution that many users are satisifed with and > which >>> works well in SE as well as in Weblogic (Credit Suisse). Either make a >>> proposal how things can be improved or live with what we have IMO. >>> >>> 2015-01-11 16:40 GMT+01:00 Romain Manni-Bucau > <[email protected]>: >>> >>>> 2015-01-11 14:52 GMT+01:00 Anatole Tresch > <[email protected]>: >>>> > Hi Mark >>>> > >>>> > some more input: >>>> > >>>> > 2015-01-11 11:54 GMT+01:00 Mark Struberg > <[email protected]>: >>>> > >>>> >> Hi! >>>> >> >>>> >> > I do not agree. It works relatively well for >>>> >> >>>> >> > many cases. Nobody using >>>> >> > Spring did much have complains on it. >>>> >> a.) They did have huge problems. That was the reason why > they have >>>> special >>>> >> hacks for every JBoss container for example >>>> >> >>>> > For Credit Suisse and most of my colleagues it does what it > should. I >>>> > looked at the code of Spring as well, and so only very few > specifics, >>>> which >>>> > does not look to be very specialized for one JBoss version. >>>> > >>>> >>>> what about others? Spring works mainly cause it has other hacks for >>>> other environment in other modules as well. >>>> >>>> > >>>> >> b.) Springs solution now is pretty bloated because of > that. It's not >>>> just >>>> >> 20k it's rather 200k and bigger. >>>> >> >>>> > >>>> > That has various reasons, one of the are the abstractions > chosen. The >>>> > current solution in Tamaya is about 20k and does basically > exactly the >>>> same >>>> > as Spring - despite the special handling of Vfs. Perhaps we > should >>>> focus on >>>> > what was went wrong in the past and I will double check if > that would >>>> be an >>>> > issue with the current apporach. >>>> > >>>> >>>> Mark is really true saying there is *NO* way to do it right without > a >>>> SPI and letting the user change it for all not default environments >>>> (not openjdk based JVMs, custom handlers etc...). And there are > more >>>> numerous than JBoss. >>>> >>>> > CU >>>> > ANatole >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >> >>>> >> > And on top: I do not need a "perfect" > solution >>>> >> Just like to make you aware of the issue we will face with > it. >>>> >> >>>> >> >>>> >> >>>> >> > Lets take it up later at the hangout. >>>> >> +1 >>>> >> >>>> >> LieGrue, >>>> >> strub >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> > On Sunday, 11 January 2015, 11:33, Anatole Tresch > < >>>> [email protected]> >>>> >> wrote: >>>> >> > > Hi Mark >>>> >> > >>>> >> > I do not agree. It works relatively well for many > cases. Nobody using >>>> >> > Spring did much have complains on it. And on top: I > do not need a >>>> >> > "perfect" >>>> >> > solution, I need a feasible solution. Lets document > its limits and be >>>> >> with >>>> >> > it. And you example and proposal simply does not > cover my use case ;( >>>> >> > >>>> >> > Lets take it up later at the hangout. >>>> >> > >>>> >> > Cheers, >>>> >> > Anatole >>>> >> > >>>> >> > >>>> >> > 2015-01-11 11:16 GMT+01:00 Mark Struberg > <[email protected]>: >>>> >> > >>>> >> >> Anatole, again: >>>> >> >> >>>> >> >> >>>> >> >> > PROTOCOL_WSJAR >>>> >> >> >>>> >> >> >>>> >> >> All this does NOT work portably! >>>> >> >> Many people tried that many times and it simply > does NOT work that >>>> >> easily! >>>> >> >> The solution I know to work (xban-finder) > explicitly has exit >>>> points to >>>> >> >> extend archive handlers. And it is about > 200kByte of size >>>> alltogether. >>>> >> >> >>>> >> >> >>>> >> >> The problem with such a solution is that we must > support it >>>> perfectly >>>> >> >> well, or not at all... >>>> >> >> >>>> >> >> What we *could* support is a _very_ easy > solution with a prefix >>>> >> >> >>>> >> >> classpath-config:mydir/myconfig.properties >>>> >> >> vs a real URL e.g. file:// >>>> >> >> >>>> >> >> In the first case we would simply use > ClassLoader.getResources and >>>> >> >> register 0..n ConfigSources, in the second case > we register exactly >>>> >> the one >>>> >> >> URL we got handed over as parameter. >>>> >> >> >>>> >> >> Also note that any wildcard style in an URL or > classpath resource >>>> is >>>> >> NOT >>>> >> >> widely supported. Some ClassLoaders can handle > it in SOME >>>> situations, >>>> >> but >>>> >> >> most of them don't. >>>> >> >> >>>> >> >> LieGrue, >>>> >> >> strub >>>> >> >> >>>> >> >> >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > *Anatole Tresch* >>>> > Java Engineer & Architect, JSR Spec Lead >>>> > Glärnischweg 10 >>>> > CH - 8620 Wetzikon >>>> > >>>> > *Switzerland, Europe Zurich, GMT+1* >>>> > *Twitter: @atsticks* >>>> > *Blogs: **http://javaremarkables.blogspot.ch/ >>>> > <http://javaremarkables.blogspot.ch/>* >>>> > >>>> > *Google: atsticksMobile +41-76 344 62 79* >>>> >>> >>> >>> >>> -- >>> *Anatole Tresch* >>> Java Engineer & Architect, JSR Spec Lead >>> Glärnischweg 10 >>> CH - 8620 Wetzikon >>> >>> *Switzerland, Europe Zurich, GMT+1* >>> *Twitter: @atsticks* >>> *Blogs: **http://javaremarkables.blogspot.ch/ >>> <http://javaremarkables.blogspot.ch/>* >>> >>> *Google: atsticksMobile +41-76 344 62 79 > <%2B41-76%20344%2062%2079>* >>> >
