Le 28 déc. 2014 14:05, "Mark Struberg" <[email protected]> a écrit : > > Romain, I can barely parse your sentences. So I hope to interpret them correctly. > > > > If you dont manage see them at all for merging (or their key-value > > pairs if not them directly) then you cant merge correctly. > > This is just not true. One can even mathematically prove this. >
Do it, you just cant cause the merge logic depends can depend the key valueS. > You might have missed that it is possible to even 'blacklist' properties in some higher level ConfigSource. > > > > > Issue is: if system is too complex or doesnt solve it then Properties > > (or more exactly Map<String, String>) is clearly more efficient > > But a ConfigSource IS a Map<String, String>... > > Agree > LieGrue, > strub > > > > > > > On Sunday, 28 December 2014, 13:22, Romain Manni-Bucau < [email protected]> wrote: > > > If you dont manage see them at all for merging (or their key-value > > pairs if not them directly) then you cant merge correctly. I saw it > > several times and finally bypassed something very close to DS - enough > > time to care about it. > > > > Issue is: if system is too complex or doesnt solve it then Properties > > (or more exactly Map<String, String>) is clearly more efficient: no > > abstraction, can be changed easily when aggregating apps etc... > > > > > > Romain Manni-Bucau > > @rmannibucau > > http://www.tomitribe.com > > http://rmannibucau.wordpress.com > > https://github.com/rmannibucau > > > > > > 2014-12-28 12:47 GMT+01:00 Mark Struberg <[email protected]>: > >>> I m fully ok to remove PropertySource from the API > >> > >> I think we've lost each other. > >> > >> Tamaya PropertySource == DeltaSpike ConfigSource basically. > >> You just cannot remove this without ditching the whole project. > >> > >> The point is that a USER never operates directly with the ConfigSources. > > They are a hidden detail. IF you manually manage them in your application then > > you end up with exactly your problem - you are doomed and cannot simply enhance > > your system but you really need to rework all the applications. > >> > >> If you just say ConfigResolver#getPropertyValue("mykey") and rely > > on the ordinal mechanism then you can just add such a FilteringConfigSource as > > JAR without having to touch any of your code. If you did manage/merge/etc your > > PropertySources manually then you are doomed. That's why I don't like > > that approach. > >> > >> > >> > >> LieGrue, > >> strub > >> > >> > >> > >> > >> > >>> On Sunday, 28 December 2014, 12:22, Romain Manni-Bucau > > <[email protected]> wrote: > >>> > Would have been the same since the app is PropertySource aware. > > Can also > >>> mean we dont have PropertySource in a default impl and then it is true > > it > >>> is easy. I m fully ok to remove PropertySource from the API and make it > > an > >>> impl detail. > >>> Le 28 déc. 2014 11:59, "Mark Struberg" > > <[email protected]> a > >>> écrit : > >>> > >>>> But if you would have had this container wide > > 'AdminConfigSource' > >>> with the > >>>> nice gui, or a installation wide DatabaesConfigSource then it > > would not > >>>> have been a problem, right? > >>>> > >>>> I mean you would have to add this filter to all the 100 apps in > > the 1 day > >>>> as well, right? So it would be the exact same effort to just add 1 > >>>> FilteringConfigSource (hacky but works) with a high priority > > either, right? > >>>> That would be just adding a single jar to all your lib folders... > >>>> > >>>> > >>>> Sometimes we tend to add new mechanisms out of blindness. But the > > problem > >>>> often can be solved easily with existing tools - we just often > > don't > >>> see > >>>> them. This happens to me as well, but I'm glad to have really > > brilliant > >>>> co-workers which often stop me from doing overly complicated crazy > > things. > >>>> Happens more often than I like it ;) > >>>> > >>>> > >>>> Of course sometimes we really need to add a new mechanism. But > > this should > >>>> only be the (almost) last resort if there is no other acceptable > > way. > >>>> > >>>> There are just sooo many weirdo cases out there. Of course they > > are often > >>>> needed in production. But for such huge installations you will > > barely find > >>>> 2 companies with the exact same situation... > >>>> > >>>> > >>>> > >>>> Maybe I'm alone here but my goal is to make the 90-95% > >>> 'standard' use > >>>> cases as easy as possible out of the box. And _additionally_ have > > an SPI > >>>> layer which is very deep down to the metal and as flexible as > > possible to > >>>> allow solving more complex edge cases. > >>>> > >>>> And I honestly don't care if a programmer does need to write > > 50 lines > >>> more > >>>> for such a seldom case. It's just impossible to solve every > > problem out > >>> of > >>>> the box. That would blow up Tamaya 10x times (or even more). And > > that would > >>>> make it unfriendly (if not even 'unusable') for the 95% > > standard > >>> cases... > >>>> > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>> > >>>> > >>>> > On Sunday, 28 December 2014, 11:41, Romain Manni-Bucau < > >>>> [email protected]> wrote: > >>>> > >T hat is exactly the difference between real life and > > theory. You > >>> cant > >>>> ask > >>>> > to change 100 apps in 1 day...you have to live with > >>>> > > >>>> > Le 28 déc. 2014 10:33, "Mark Struberg" > >>> <[email protected]> a > >>>> > écrit : > >>>> > > >>>> >> I don't get your samples Romain. > >>>> >> > >>>> >> In v1 you have configured keys A,B,C > >>>> >> In v2 you have D. So what? > >>>> >> > >>>> >> Just remove A,B,C and use D instead. That's exactly > > the same > >>> like > >>>> > changing > >>>> >> a table structure. > >>>> >> > >>>> >> Doing some 'translation' just because the ops > > guys > >>> don't want > >>>> > to change > >>>> >> configuration is a total dead end and will end up being > > a > >>> maintenance > >>>> >> nightmare in v3++. Your filter mechanism is just an > > utter ugly > >>> hack > >>>> and if > >>>> >> I would be the manager of this project then I'd call > > you > >>> names ;) > >>>> >> > >>>> >> That's like arguing that maven is not usable because > > it makes > >>> scripting > >>>> >> hard. This is a FEATURE and not a bug!. People should > > not script > >>>> builds! If > >>>> >> they like to do complicated stuff then it's very > > easy to > >>> write plugins. > >>>> > In > >>>> >> our case it's very easy to write ConfigSources. > >>>> >> > >>>> >> > >>>> >> Remember the old saying "dirty remains, while quick > > is long > >>>> > forgotten" > >>>> >> > >>>> >> > >>>> >> > Some config can conflict > >>>> >> > >>>> >> No. That's the same like with JNDI, JMX etc. Just > > tell them > >>> to use > >>>> > their > >>>> >> own namespaces and you are done. > >>>> >> That's like saying Java is not good because if I > > have > >>> multiple JARs > >>>> > which > >>>> >> contain the same ClassName then it doesn't work. > > JUST USE > >>> NAMESPACES. > >>>> > You > >>>> >> don't need any explicit merging. > >>>> >> > >>>> >> > >>>> >> > >>>> >> Oki, that was 2 arguments and both of them are actually > >>> non-problems. > >>>> >> > >>>> >> Cmon folks, give me more use cases and examples. I'm > > ready to > >>> solve > >>>> > them ;) > >>>> >> > >>>> >> > >>>> >> LieGrue, > >>>> >> strub > >>>> >> > >>>> >> On Sunday, 28 December 2014, 9:54, Romain Manni-Bucau > > < > >>>> >> [email protected]> wrote: > >>>> >> >Well more I read more I think there is a real need > > but we are > >>> all > >>>> wrong > >>>> >> so instead of fighting please help us finding a > > solution. > >>>> >> >@Mark: priorities or ordinal are great while you > > completely > >>> own the > >>>> app > >>>> >> and its config + it is a single technical version. I > > guess you > >>> know it > >>>> is > >>>> >> not always (rarely?) The case in medium and big > > projects. > >>>> >> >A sample can be: v1 you configure an url with host, > > port > >>> propertkes > >>>> and > >>>> >> in v2 it is directly the url cause you added a path. Can > > be the > >>> same > >>>> for > >>>> >> datasource and business config etc... > >>>> >> >What I did in practise was to use a filter mecanism > > but it > >>> was an ugly > >>>> >> hack. > >>>> >> >For such cases you can maybe use PropertySource > > translators > >>> or things > >>>> >> like that to ensure the config is in the right format > > and then > >>> merge > >>>> with > >>>> >> ordinal. > >>>> >> >Now let take the case where you package together > > several sub > >>> apps > >>>> > coming > >>>> >> with their config. How do you do? Some config can > > conflict and > >>> the > >>>> >> selection is not ordinal based - let me guess it will be > > the > >>> same. > >>>> Best is > >>>> >> to have both property sources and merge them into a > > single one. > >>> Kind of > >>>> >> Properties merge(Properties current, PropertySource > > next). > >>>> >> >I am not happy with these solutions but the needs > > are here > >>> and not > >>>> >> something thought but really met - even if I dont have > > your > >>>> experiences. > >>>> >> >Point is we cant assume config will be perfect so > > let our > >>> future users > >>>> >> make errors and be able to fix it easily. > >>>> >> >Le 27 déc. 2014 14:50, "Mark Struberg" > >>>> > <[email protected]> a écrit : > >>>> >> >> > >>>> >> >> No Anatole, I DO get it, but I really think it > > is a bad > >>> idea. > >>>> > Because > >>>> >> it adds way too much complexity or a very limited > > benefit. > >>>> >> >> > >>>> >> >> > >>>> >> >> Think about it in an analogy to the > > ExpressionLanguage > >>> ELResolver > >>>> >> chain. Of course this is a sorted lookup chain. And this > > list is > >>> fixed! > >>>> >> >> > >>>> >> >> And at runtime you cannot change the order and > > the user > >>> also does > >>>> > not > >>>> >> care! > >>>> >> >> All he cares is that #{user.name} does the > > right > >>> thing. He > >>>> > does not > >>>> >> have to express an 'evaluator' and the chain > > ordering for > >>> each and > >>>> > every EL > >>>> >> invocation. It just does not make any sense from a users > >>> perspective. > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> LieGrue, > >>>> >> >> strub > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> > >>>> >> >> On Saturday, 27 December 2014, 14:17, Anatole > > Tresch > >>> < > >>>> >> [email protected]> wrote: > >>>> >> >> > >>>> >> >> > >>>> >> >> > > >>>> >> >> > > >>>> >> >> >Hi Mark > >>>> >> >> > > >>>> >> >> > > >>>> >> >> >2014-12-27 12:56 GMT+01:00 Mark Struberg > >>>> > <[email protected]>: > >>>> >> >> > > >>>> >> >> >> The mechanism is clumsy and implies > >>>> >> >> >>> constraints that are already known > > as of > >>> now not > >>>> > matching all use > >>>> >> cases. > >>>> >> >> >> > >>>> >> >> >>Tell me some limitations. Never had > > one. So just > >>> enlist > >>>> > them here and > >>>> >> now. > >>>> >> >> >> > >>>> >> >> >And I am working since decades as well in > > the > >>> industry. I > >>>> > will not > >>>> >> argue about use cases. I gave you same examples. You > > have the > >>> stand my > >>>> >> opinion, unless you feel your opinion counts more than > > mine. > >>>> >> >> > > >>>> >> >> >> On top of it the priority leaks into > > the > >>> PropertySource > >>>> > API > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >>Because it IS part of the > > PropertySource! > >>>> >> >> >> > >>>> >> >> > > >>>> >> >> >But it shoud not. I want to have my > > property > >>> sources and I > >>>> > want to > >>>> >> combine them they way I want it. I want the concern of > > assembly > >>> being > >>>> >> separated from the source itself. > >>>> >> >> >It is like you write a Java program like > > this: > >>>> >> >> > > >>>> >> >> > > >>>> >> >> >2: { > >>>> >> >> >4: } > >>>> >> >> > > >>>> >> >> >3: System.out.println(); > >>>> >> >> >1: for(int i=0;i<10;i11) > >>>> >> >> > > >>>> >> >> > > >>>> >> >> > > >>>> >> >> >Shows pretty much the nonsense of your > >>> argumentation. For > >>>> > priorizing > >>>> >> the loading of components in CDI priorities are great > > and > >>> sufficient, > >>>> here > >>>> >> they are not. > >>>> >> >> > > >>>> >> >> > > >>>> >> >> >> Finally functions is the > >>>> >> >> >> > >>>> >> >> >>> modern way of modelling such an > > operation. > >>>> >> >> >> > >>>> >> >> >>If you have a hammer... > >>>> >> >> >>I'm not interested in style if it > >>> doesn't add any > >>>> > real benefit. > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >If the hammer is more elegant and powerful > > but > >>> still easy > >>>> > than you > >>>> >> outstyled solution, let it be a hammer! > >>>> >> >> > > >>>> >> >> >>> different or > >>>> >> >> >> > >>>> >> >> >>> partial overridings (common in > > complex > >>> environments) > >>>> >> >> >> > >>>> >> >> >>Never came across this need and I did > > very > >>> complex > >>>> > projects. It's > >>>> >> always a trade off between an easy straight forward > > algorigthm > >>> which > >>>> are > >>>> >> easy to understand but sometimes you have to bend em a > > bit or > >>> program > >>>> your > >>>> >> own (PropertySource). The other option is to have hugely > > complex > >>> base > >>>> >> mechanism which noone can use in practice because it is > > 'too > >>>> > flexible' - > >>>> >> means not clear and straight enough. > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >>> you will never get one solution, > > which a > >>> special type > >>>> > of > >>>> >> >> >> > >>>> >> >> >>> overridings that matches all > > users. > >>>> >> >> >>Oh sure we do. By having the > > ConfigSource define > >>> their > >>>> > ordinal > >>>> >> themselves and it being really easy for a programmer to > > add own > >>>> >> ConfigSources we have all of that! > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >>> A solution should NEVER constraint > > users in > >>> doing the > >>>> > stuff > >>>> >> >> >>> they want!* > >>>> >> >> >> > >>>> >> >> >>Having the sorting via Ordinal > > doesn't > >>> impose any > >>>> > restriction on the > >>>> >> user. Because he can easily overwrite those values. > >>>> >> >> >>We are talking about a simple straight > > forward > >>> config > >>>> > mechanism and > >>>> >> not about alien rocket science and time travelling. > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >>>You are not on green field here! > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >>Oh boy, we are! We just need to fulfil > > user > >>> needs, > >>>> > that's all. > >>>> >> >> >I am not a boy. I am an adult with 44 years > > on > >>> track.... ! > >>>> >> >> >And BTW you seem to have lost every kind of > > reality > >>> contact. > >>>> > Do you > >>>> >> really think companies will change their internal > > systems > >>> completely > >>>> >> because just a few guys think they know > >>>> >> >> >how the world is rouling...? NO! > >>>> >> >> > > >>>> >> >> >> > >>>> >> >> >>> *Of course not! (despite the fact > > that is > >>> trivial > >>>> > for the ones > >>>> >> used the > >>>> >> >> >>> functional style of Java 8). > >>>> >> >> >>Of course I know Map#merge, but what do > > you use > >>> it for? To > >>>> > me it > >>>> >> seems like an overkill. > >>>> >> >> >Seems that your mindis still stick on Java > > 7.,,, > >>>> >> >> > > >>>> >> >> >> You can still provide a singleton with > >>>> >> >> >>> constants, where you* > >>>> >> >> >>> *provide the most common > > combinations, see > >>>> > AggregationPolicy in my > >>>> >> the > >>>> >> >> >>> current tree.* > >>>> >> >> >> > >>>> >> >> >>Again: I don't see the benefit. If > > I'm > >>> in an EAR > >>>> > and like to get my > >>>> >> "documentarchive.endpoint.url" then WHY would > > I like to > >>> manually > >>>> > change the > >>>> >> aggregation? Makes no sense to me. And this increases > > the > >>> complexity > >>>> quite > >>>> >> impressively. > >>>> >> >> >> > >>>> >> >> > > >>>> >> >> > > >>>> >> >> >Perhaps one day you realize that we are > > talking > >>> about a > >>>> > general > >>>> >> configuration soultion. EE is a sepcial case, not the > > other way > >>> round. > >>>> It > >>>> >> is NOT like Deltaspike, which benefits the mechanism > > provided by > >>> CDI. > >>>> It is > >>>> >> not and if it will, it gets Deltaspike 2, which is > > useless. There > >>> is > >>>> >> already one, which for its purposes on this level, I > > agree, works > >>>> well. But > >>>> >> for a general solution it lacks so much on > > functionality- > >>>> >> >> > > >>>> >> >> > > >>>> >> >> >I personally really think you still do not > > get the > >>>> > difference! It > >>>> >> drives me crazy. > >>>> >> >> > > >>>> >> >> >LieGrue, > >>>> >> >> >>strub > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >> > >>>> >> >> >>> On Saturday, 27 December 2014, > > 12:28, > >>> Anatole Tresch > >>>> > < > >>>> >> [email protected]> wrote: > >>>> >> >> >>> > *See inline...* > >>>> >> >> >>> > >>>> >> >> >>> 2014-12-27 11:42 GMT+01:00 Mark > > Struberg > >>>> > <[email protected]>: > >>>> >> >> >>> > >>>> >> >> >>>> Hi! > >>>> >> >> >>>> > >>>> >> >> >>>> 1.1) > >>>> >> >> >>>> > >>>> >> >> >>>> I think we agree that having > > a > >>>> > PropertySource/ConfigSource SPI > >>>> >> with MANY > >>>> >> >> >>>> implementations is the way to > > go? > >>>> >> >> >>>> Any objections? > >>>> >> >> >>>> > >>>> >> >> >>> *+1 The way to go.* > >>>> >> >> >>> > >>>> >> >> >>> > >>>> >> >> >>> 1.2) > >>>> >> >> >>>> > >>>> >> >> >>>> Where should it belong to? Is > > it an > >>> API or > >>>> > rather an SPI? > >>>> >> >> >>>> I think it's more the > > later. A end > >>> user just > >>>> > likes to get the > >>>> >> >> >>> 'final' > >>>> >> >> >>>> configured values and does > > NOT deal > >>> with the > >>>> > PropertySources > >>>> >> himself. It is > >>>> >> >> >>>> really just for extending the > > system > >>> -> SPI. > >>>> >> >> >>>> > >>>> >> >> >>> *+1 for PropertySource being an > > SPI. > >>> Configuration > >>>> > must be the > >>>> >> API.* > >>>> >> >> >>> > >>>> >> >> >>> > >>>> >> >> >>> 1.3) > >>>> >> >> >>>> Merging. > >>>> >> >> >>>> Option (1.3.a) Do we like to > > do > >>>> > 'implicit' merging (aka the > >>>> >> >> >>> ordinal > >>>> >> >> >>>> stuff). > >>>> >> >> >>>> > >>>> >> >> >>> *It's not a question of taste. > > The > >>> mechanism is > >>>> > clumsy and implies > >>>> >> >> >>> constraints that are already known > > as of > >>> now not > >>>> > matching all use > >>>> >> cases. On > >>>> >> >> >>> top of it the priority leaks into > > the > >>> PropertySoiurce > >>>> > API (as an > >>>> >> additional > >>>> >> >> >>> method, which is a very ugly mix > > of > >>> concerns), > >>>> > Finally functions is > >>>> >> the > >>>> >> >> >>> modern way of modelling such an > > operation.* > >>>> >> >> >>> > >>>> >> >> >>> > >>>> >> >> >>>> Option (1.3.b) Or do we like > >>> 'explicit' > >>>> > (the merge function). What > >>>> >> >> >>> benefit > >>>> >> >> >>>> does this add in practice? > >>>> >> >> >>>> > >>>> >> >> >>> > >>>> >> >> >>> *See above and as outlined > > multiple times. > >>> Adding > >>>> > additional > >>>> >> functionality > >>>> >> >> >>> for audit (e.g. logging of the > >>> configuration > >>>> > overriding), different > >>>> >> or > >>>> >> >> >>> partial overridings (common in > > complex > >>> environments). > >>>> > Please stop > >>>> >> >> >>> discussion on this priority thing, > > it's > >>> simply > >>>> > not enough! By the > >>>> >> way the > >>>> >> >> >>> priority thing can still be > > implemented, > >>> when the > >>>> > rest of the > >>>> >> design is > >>>> >> >> >>> done in a modular way. My proposed > > solution > >>> gave you > >>>> > the > >>>> >> abtrsaction of a > >>>> >> >> >>> ConfigProvider BTW, where you > > could do this > >>> easily, > >>>> > but also the > >>>> >> other > >>>> >> >> >>> stuff. What you do depends on the > > use case, > >>> and to > >>>> > some extent your > >>>> >> >> >>> personal taste. A solution should > > NEVER > >>> constraint > >>>> > users in doing > >>>> >> the stuff > >>>> >> >> >>> they want!* > >>>> >> >> >>> > >>>> >> >> >>> Ad 1.3.a 'explicit' > > merging: This > >>> is > >>>> > basically the DeltaSpike mode: > >>>> >> EACH > >>>> >> >> >>>> ConfigSource (PropertySource) > > has an > >>> ordinal > >>>> > which it can set > >>>> >> itself. The > >>>> >> >> >>>> higher the configuration > > ordinal of > >>> the > >>>> > ConfigSource, the more > >>>> >> important it > >>>> >> >> >>>> is and it will override > > values from > >>>> > ConfigSources with lower > >>>> >> ordinal. > >>>> >> >> >>>> > >>>> >> >> >>>> That way it is possible to > > have a kind > >>> of > >>>> > 'default configuration' > >>>> >> >> >>> e.g. in > >>>> >> >> >>>> a property file inside your > > project > >>> and later > >>>> > overwrite it via > >>>> >> -Dxxx=yyy, > >>>> >> >> >>>> JNDI, or some container > > provided > >>>> > MyCountainerAdminConfigSource > >>>> >> etc later. > >>>> >> >> >>>> > >>>> >> >> >>> *No Mark. The fact of having a > > default > >>> configuration > >>>> > does not > >>>> >> interconnect > >>>> >> >> >>> how this is evaluated and > > composed. You are > >>> wrong! > >>>> > And on top, > >>>> >> when I look > >>>> >> >> >>> at your ideas: you will never get > > one > >>> solution, which > >>>> > a special > >>>> >> type of > >>>> >> >> >>> overridings that matches all > > users. You > >>> have to > >>>> > provide building > >>>> >> blocks > >>>> >> >> >>> (one more) that helps the users > > (companies) > >>> to model > >>>> > their > >>>> >> functionality > >>>> >> >> >>> with it. You are not on green > > field here!* > >>>> >> >> >>> > >>>> >> >> >>> Ad 1.3.b 'implicit' > > merging: Well, > >>> actually I > >>>> > don't got this. There > >>>> >> >> >>> was > >>>> >> >> >>>> merge(String key, > > PropertySource s1, > >>> s2), but > >>>> > that would mean > >>>> >> that every > >>>> >> >> >>>> user needs to deal with that > > himself? > >>> Could you > >>>> > please elaborate > >>>> >> on that > >>>> >> >> >>>> option? I didn't get it.. > >>>> >> >> >>> > >>>> >> >> >>> *Of course not! (despite the fact > > that is > >>> trivial > >>>> > for the ones > >>>> >> used the > >>>> >> >> >>> functional style of Java 8). You > > can still > >>> provide a > >>>> > singleton with > >>>> >> >> >>> constants, where you* > >>>> >> >> >>> *provide the most common > > combinations, see > >>>> > AggregationPolicy in my > >>>> >> the > >>>> >> >> >>> current tree.* > >>>> >> >> >>> > >>>> >> >> >>> *-Anatole* > >>>> >> >> >>> > >>>> >> >> >>> > >>>> >> >> >>>> > >>>> >> >> >>>> > >>>> >> >> >>> > >>>> >> >> >>>> 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/ > >>>> >> >> >Google: atsticks > >>>> >> >> >Mobile +41-76 344 62 79 > >>>> >> >> > > >>>> >> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > >>>> > > >>>> > >>> > >
