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 b.) Springs solution now is pretty bloated because of that. It's not just 20k it's rather 200k and bigger. > 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 >> >>
