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>* >>
