[Java] Oplossen van veel voorkomende problemen?

[Maniacs]

Hallo,

Eerst even een voorafje: Ik ben nu ongeveer 8 jaar werkzaam als java programmeur voor verschillende bedrijven op verschillende projecten. Ondanks dat ik, Java een heel leuk platform vind om in te programmeren loop je met elk project weer tegen dezelfde basic "problemen" aan. Denk aan de keuzes uit logging framework (log4j, jul, slf4j?), omgaan met configuratie instellingen (properties, jmx, xml, of in een database?), events etc. M.i. had Sun al die problemen al jaren geleden moeten oplossen in de runtime, maar dat is helaas niet gebeurd. Apache heeft gelukkig een boel projecten die een groot deel hiervan oplossen, maar een groot nadeel hiervan is dat deze projecten slecht met elkaar samenwerken.

Al die tijd heb ik de "problemen" waar ik tegenaan liep geprobeerd generiek op te lossen wat hergebruik tussen verschillende projecten mogelijk maakte. De code hiervan is in 1 library gebundeld zodat je met 1 dependency de meeste basic problemen elke keer op dezelfde manier kunt oplossen. Tot nog toe hield ik de code altijd voor mezelf wat me een kleine voorsprong kon geven tegenover de concurrentie Aangezien ik nu een andere insteek heb kan ik misschien iemand anders er blij mee maken. Dus mocht je je ook zo irriteren aan de gebrekkigheid van de runtime, knock yourselves out
Sources: hier, svn hier
Jar: hier
Reference documentation in steenkolen engels: hier, handig trouwens dat docbook!

klein overzicht van wat t kan:
* logging via <je favoriete logger> per gebruiker en/of per service in te stellen.
* configuratie opslag in properties, plain java of xml (alleen in trunk).
* plain java async events.
* persistency "framework", nu nog allen in-memory (volgende wellicht ook naar een DB of files).
* Runnable uitvoeren in managed threads indien van toepassing (alleen in trunk).
* standaard set van geinternationaliseerde excepties.
* Singletons in een cluster (alleen in trunk).

Ok, op deze manier begint het wellicht op een promotie actie te lijken maar dat is echt niet de bedoeling! Rip gerust hetgeen je kan gebruiken en kraak de rest lekker af

Groeten,
Mark

[ACM]

Ben je nou niet een concurrent voor Spring en vergelijkbare IoC-frameworks aan het maken? Overigens doet slf4j zelf toch al wat jij in je eerste feature beschrijft?

[Gerco]

Op zich vind ik dit een nobel streven, maar helaas zorgen dit soort initiatieven voor het verergeren van het probleem in plaats van een echte oplossing te bieden. In plaats van de keuze tussen x frameworks voor logging, etc heb je nu opeens x+1 keuzes.

Spring biedt niet alles wat een applicatie nodig heeft (geen logging abstractie bijvoorbeeld), maar heeft wel weer andere dingen die jouw framework niet heeft. Jouw framework heeft weer dingen die framework x niet heeft, maar framework y wel. Ik denk niet dat het mogelijk is om een framework te bieden wat voor elke applicatie goed genoeg is.

Je app samenstellen uit een stapeltje libraries die allemaal 1 ding doen (en dat ene ding dan goed) vind ik zo slecht nog niet.

[Maniacs]

ACM schreef op maandag 18 januari 2010 @ 10:12:
Ben je nou niet een concurrent voor Spring en vergelijkbare IoC-frameworks aan het maken?

Hehe hoop het niet. Lijkt me ook stug, er zit 0.0 aan IoC in.

Gr,
Mark

[Maniacs]

Gerco schreef op maandag 18 januari 2010 @ 10:25:
Op zich vind ik dit een nobel streven, maar helaas zorgen dit soort initiatieven voor het verergeren van het probleem in plaats van een echte oplossing te bieden. In plaats van de keuze tussen x frameworks voor logging, etc heb je nu opeens x+1 keuzes.

Klopt, er is er maar 1 die het goed zou kunnen oplossen: Sun/Oracle. Maar zolang die niet verder als JUL komen zal het wel altijd zo blijven. Van logging zou je toch standaard iets meer willen verwachten? Ik wel in ieder geval Denk aan: Welke database queries heeft een gebruiker afgevuurd, welke requests komen van welke gebruiker etc. En hoe lang duren die requests? Allemaal functionaliteits die volgens mij prima in de runtime zou kunnen zitten maar nu idd volgens het x+1 beleid worden geimplementeerd.

Gr,
Mark

[ACM]

Maniacs schreef op maandag 18 januari 2010 @ 10:38:
Hehe hoop het niet. Lijkt me ook stug, er zit 0.0 aan IoC in.

Of je wel/niet IoC gebruikt was voor mijn vraag niet zo relevant, ik doelde meer op de rest van Spring, dat ze voor veel standaard bibliotheken zelf wrappers aanleveren.

Maniacs schreef op maandag 18 januari 2010 @ 10:48:
Klopt, er is er maar 1 die het goed zou kunnen oplossen: Sun/Oracle. Maar zolang die niet verder als JUL komen zal het wel altijd zo blijven. Van logging zou je toch standaard iets meer willen verwachten? Ik wel in ieder geval

Tegelijkertijd heeft 'iedereen' weer andere eisen, verwachten ze slechts een deel van de functionaliteit of werkt de aangeleverde functionaliteit toch niet zoals gewenst. Dus uiteindelijk is het misschien niet zo gek dat ze dan verwachten dat je zelf kiest.

Denk aan: Welke database queries heeft een gebruiker afgevuurd, welke requests komen van welke gebruiker etc.

Tegelijkertijd moet je je afvragen of dat functionaliteit is die altijd uitgevoerd moet worden. Als je met een heel hoog tempo heel veel queries wilt uitvoeren, is het niet zo handig om flink wat logging te genereren, zelfs niet als het loggen allemaal uitgezet is in de configuratiebestanden.

[NLxAROSA]

Het feit dat iemand zijn spulletjes open-sourcet waar hij zelf veel profijt van heeft gehad kun je geen bezwaar tegen hebben toch? Ook al worden de meeste zaken al opgelost door andere frameworks.

Waar ik wel benieuwd naar ben: welke Apache projecten vind jij dan slecht met elkaar samen werken?

Maniacs schreef op maandag 18 januari 2010 @ 10:38:
[...]

Hehe hoop het niet. Lijkt me ook stug, er zit 0.0 aan IoC in.

Of je wel of geen IoC gebruikt heeft weinig te maken met het feit dat veel van jouw oplossingen ook door Spring worden aangeboden (eventueel in samenwerking met andere frameworks/producten).

[ Voor 0% gewijzigd door NLxAROSA op 18-01-2010 11:11 . Reden: typo ]

[Maniacs]

NLxAROSA schreef op maandag 18 januari 2010 @ 11:10:
Waar ik wel benieuwd naar ben: welke Apache projecten vind jij dan slecht met elkaar samen werken?

Voorbeeld: Commons-configuration wordt zelden gebruikt in overige jakarta-commons projecten; Zo zou commons-email of commong-logging hier prima gebruik van kunnen maken. Bijna al die projecten hebben eigen (system)properties / files om de functionaliteit te configureren.
Wat ik ook wel jammer vind is dat de gehele commons suite (om het zo maar te noemen) niet onder 1 versie gereleased wordt. Dit zou het onderlinge dependency managemend wat vergemakkelijken. Maven lost dit natuurlijk wel op door automatisch de hoogste versie te kiezen, maar of het dan ook daadwerkelijk werkt kan veel testuren kosten.

Of je wel of geen IoC gebruikt heeft weinig te maken met het feit dat veel van jouw oplossingen ook door Spring worden aangeboden (eventueel in samenwerking met andere frameworks/producten).

Ok, er werd gesproken over Spring en andere IoC frameworks. Vandaar dat ik dacht dat het om de IoC ging.

Tegelijkertijd moet je je afvragen of dat functionaliteit is die altijd uitgevoerd moet worden. Als je met een heel hoog tempo heel veel queries wilt uitvoeren, is het niet zo handig om flink wat logging te genereren, zelfs niet als het loggen allemaal uitgezet is in de configuratiebestanden.

Ik begrijp niet helemaal wat je met die laatste regel bedoelt, maar idd. Ik werk aan een HA applicatie die in een cluster draait. De verkeerde logger op debug zetten heeft meteen performance impact. Trouwens, probeer maar eens in een cluster de logging te manager. Met wat geluk heeft je applicatieserver de basic mogelijkheden, anders moet je zelf weer aan de slag.

Gr,
Mark

[Gerco]

Maniacs schreef op maandag 18 januari 2010 @ 10:48:
Klopt, er is er maar 1 die het goed zou kunnen oplossen: Sun/Oracle. Maar zolang die niet verder als JUL komen zal het wel altijd zo blijven. Van logging zou je toch standaard iets meer willen verwachten?

JUL is inderdaad niet bepaald een geweldige library. Ik heb er menig uurtje ingestoken om eruit te krijgen wat ik eruit wilde hebben. De makkelijkste manier om dat voor elkaar te krijgen is volgens mij SL4J erin steken en aan log4j koppelen.

Denk aan: Welke database queries heeft een gebruiker afgevuurd, welke requests komen van welke gebruiker etc. En hoe lang duren die requests?

Dit lijkt me geen functionaliteit voor een logging framework om in te bouwen. Meer iets voor een persistence manager of een servlet container (resp.). Indien die het niet bieden kun je natuurlijk altijd nog iets als AOP gebruiken om het alsnog toe te voegen.

[Herko_ter_Horst]

Zoals al gezegd: dit is framework x+1. Heeft het meerwaarde? Voor sommigen wel, voor anderen niet.

Een one-size-fits-all oplossing bestaat volgens mij niet. Dit is dus ook niet iets voor Oracle/Sun om op te lossen. De standaard libraries zijn al veel te uitgebreid, wat mij betreft. Een modulair opgebouwde runtime, waar je zelf je favo frameworks aan toe kunt voegen, lijkt mij veel interessanter.

[Hydra]

@TS: lijkt een beetje op de not invented here antipattern

NLxAROSA schreef op maandag 18 januari 2010 @ 11:10:
Waar ik wel benieuwd naar ben: welke Apache projecten vind jij dan slecht met elkaar samen werken?

Wat ik zelf slecht vind en zelf tegenaanloop is dat er erg weinig support is voor Apache projecten en de documentatie ronduit slecht is. Ik heb voor verschillende issues gestaan met Axis2 bijvoorbeeld, en een daarvan (werkt niet lekker samen met Spring vanwege de manier waarop Axis2 met classpaths omgaat) wordt gewoon niet als issue gezien maar een incident wordt met het commentaar "By design" gesloten. Goed voorbeeld bijvoorbeeld zijn de Eclipse plugins om een AAR te deployen: werken gewoon niet.

Natuurlijk, het is open source dus fix zelf die bugs, maar daar heb ik simpelweg de tijd niet voor.

[Maniacs]

Gerco schreef op maandag 18 januari 2010 @ 13:49:
[...]
Dit lijkt me geen functionaliteit voor een logging framework om in te bouwen. Meer iets voor een persistence manager of een servlet container (resp.). Indien die het niet bieden kun je natuurlijk altijd nog iets als AOP gebruiken om het alsnog toe te voegen.

Idd, 1 op 1 moet je dit natuurlijk niet in een logger system willen. Wat ik bedoel is dat het handig zou zijn als logging statements in een context geplaatst zouden kunnen worden. Misschien ben ik de enige die er zo over denkt hoor, maar ik vind dat waar het java platform echt wel veel mooie dingen m.b.t. clustering en scalability voortbrengt er over het algemeen vrij weinig ondersteuning/mogelijkheden voor de beheeraspecten biedt.
Verder, zoals ik al zei, ik post hier niet met de intentie een vervanger voor wat dan ook maar te bieden. Ik loop al jaren tegen een aantal problemen aan die ik op een bepaalde manier heb opgelost. Mocht er iemand zijn die er op wat voor manier dan ook z'n voordeel mee kan doen, mooi! zo niet, dan niet

Gr,
Mark

[NLxAROSA]

Gerco schreef op maandag 18 januari 2010 @ 13:49:
[...]

JIndien die het niet bieden kun je natuurlijk altijd nog iets als AOP gebruiken om het alsnog toe te voegen.

Iets waar bijvoorbeeld de autoproxy functionaliteit van Spring erg geschikt voor is.

Hydra schreef op maandag 18 januari 2010 @ 14:56:
@TS: lijkt een beetje op de not invented here antipattern


[...]


Wat ik zelf slecht vind en zelf tegenaanloop is dat er erg weinig support is voor Apache projecten en de documentatie ronduit slecht is.

Dat vind ik persoonlijk nou niet iets unieks van de Apache projecten.