[java] Wat is jullie ervaring met Spring?

maandag 31 oktober 2005 09:14

iPhone 30! Bam!

Ik heb er jammer genoeg nog helemaal geen ervaring mee. Heb er ondertussen al genoeg over gelezen, zowel hier als op andere sites en ben er ook erg enthousiast over.
Ik hoop het iig in een volgend project zeker te kunnen gebruiken.

[edit]
Ik ben wel benieuw naar de ervaringen met Spring MVC. Ik werk nu nog veel met Struts en ben wel benieuwd of Spring MVC dan een goede vervanger is (of gewoon echt beter). Of dat er andere, betere oplossingen zijn icm Spring

[ Voor 34% gewijzigd door momania op 31-10-2005 08:40 ]

Neem je whisky mee, is het te weinig... *zucht*

Acties:

maandag 31 oktober 2005 09:31

-= Tja =-

Topicstarter

Ik ben wel benieuw naar de ervaringen met Spring MVC. Ik werk nu nog veel met Struts en ben wel benieuwd of Spring MVC dan een goede vervanger is (of gewoon echt beter). Of dat er andere, betere oplossingen zijn icm Spring

Ik heb zelf weinig praktische ervaring met Struts en Spring MVC, maar het zijn model2 based frameworks en imho zijn die achterhaald. Pagebased/componentbased webframeworks zijn de toekomst, en hierbij moet je denken aan: JSF, Tapestry, Wicket. Ik heb zelf wel ervaring met een ander model2 based framework, namelijk Maverick, en ik moet eerlijk toegeven dat mijn productie snelheid met ca een factor 100 is afgenomen (als ik het vergelijk met Swing). Bij het bedrijf waar ik werk hebben we een aantal toevoegingen hierop gedaan, zodat we wel pagebased kunnen werken, en de algemene conclusie is dat het gewoon veel sneller en natuurlijker werkt.

Uit ervaring weet ik dan Tapestry en Wicket goed te combineren zijn met Spring. Ik durf te wedden dat JSF ook wel geintegreerd kan worden, maar hier heb ik geen ervaring mee.

[ Voor 14% gewijzigd door Alarmnummer op 31-10-2005 09:22 ]

Acties:

maandag 31 oktober 2005 09:31

iPhone 30! Bam!

Ok, dan weet ik dat ik bij m'n eerste Spring ervaring dus beter direct naar Tapestry en/of Wicket kan kijken dan SpringMVC

Struts wilde ik sowoeso al laten vallen, maar ik dacht misschien dat SpringMVC nog wel interessant kon zijn aangezien het door dezelfde personen is gemaakt (toch?) en dus waarschijnlijk een hoop verbeterd zou moeten zijn tov Struts.
Dat het dan model2 based blijft zou ik op zich niet zoveel problemen mee hebben, maar ik heb dan ook nog geen ervaring met pagebased.

Maar pagebased klinkt iig een stuk simpeler idd dus ben wel benieuwd

[ Voor 45% gewijzigd door momania op 31-10-2005 09:33 ]

Neem je whisky mee, is het te weinig... *zucht*

Acties:

maandag 31 oktober 2005 09:33

Moderator Devschuur®

!litemod

Spring en struts zelf zijn redelijk goed te combineren. Het enige probleem hierbij is dat acties dubbel gedefinieerd moeten worden (in je struts config bij het actie gedeelte eigenlijk alleen de forms en de forwards en in je spring config vervolgens de gebruikte classes en de geinjecteerde objecten). Het werkt wel goed. Je hoeft je al gemaakte code en structuren nauwelijks overboord te gooien. Spring gebruik je er gewoon 'bij'. Ik blijf echter wel het gevoel houden dat het niet goed op elkaar aansluit (juist door die dubbele config). Ik volg dan ook geintreseerd projecten als Struts Shale en JSF. Helaas heb ik op mijn werk nu erg weinig tijd (lees geen tijd voor onderzoek, alles moet op projecten geboekt kunnen worden) om hier eens goed naar te kunnen kijken.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

maandag 31 oktober 2005 09:36

Moderator Devschuur®

!litemod

Owh, en laat je niet teveel afleiden door Alarmnummers 100% afname in productiviteit. Ik vermoed dat dat meer te maken heeft met de overstap van client applicatie naar web applicatie dan met struts vs JSF

. Als je al (veel) met struts gewerkt hebt dan hoef je dat niet gelijk overboord te gooien.

[ Voor 19% gewijzigd door Janoz op 31-10-2005 09:34 ]

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

maandag 31 oktober 2005 09:38

iPhone 30! Bam!

Janoz schreef op maandag 31 oktober 2005 @ 09:33:
Owh, en laat je niet teveel afleiden door Alarmnummers 100% afname in productiviteit.

lol

Doe ik zeker niet... Alarmnummer kan het soms overdrijven (

), maar toch zie ik er wel vaak goede ideeen in

Ik zou hem daardoor eerder super fantiek noemen

Neem je whisky mee, is het te weinig... *zucht*

Acties:

maandag 31 oktober 2005 09:44

-= Tja =-

Topicstarter

Janoz schreef op maandag 31 oktober 2005 @ 09:33:
Owh, en laat je niet teveel afleiden door Alarmnummers 100% afname in productiviteit. Ik vermoed dat dat meer te maken heeft met de overstap van client applicatie naar web applicatie dan met struts vs JSF .

Dat is helaas niet zo. Het komt puur voort uit het feit dat simpele dingen complex zijn en complexe dingen (nagenoeg) onmogelijk met model2 based frameworks. Ik heb een project met Tapestry gedaan en had meteen weer het gevoel om thuis te komen. Doordat het webframework een hele lading voor je doet (bv events aanroepen op de pagina) ben je van zoveel geneuzel verlost en verder kun je veel natuurlijker denken in termen van pagina`s en componenten.

Maar laten we hier geen anti-model2 topic van maken

[ Voor 4% gewijzigd door Alarmnummer op 31-10-2005 09:41 ]

Acties:

maandag 31 oktober 2005 09:54

Moderator Devschuur®

!litemod

Dat is ook wel zo, maar zeker voor een overstap van non Spring naar een Spring omgeving vind ik dat je niet gelijk alles moet vernieuwen. Nattuurlijk zijn er verschillende dingen lastiger, maar een overstap waarbij je je complete bestaande codebase overboord gooit lijken me nou ook niet echt makkelijk. Uitgaande van een systeem met struts kun je een aantal dingen doen. Je kunt spring introduceren en struts blijven gebruiken en als dat allemaal goed draait eens kijken of je ook over wilt stappen op tapestry of JSF. Je kunt ook gelijk alles doen. Als je tussen deze twee gevallen kunt kiezen gaat mijn voorkeur dan toch echt naar het eerste uit.

Daarnaast kun je mbv tiles ook nog redelijk 'component'-based werken met struts.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

maandag 31 oktober 2005 10:18

-= Tja =-

Topicstarter

Janoz schreef op maandag 31 oktober 2005 @ 09:44:
Dat is ook wel zo, maar zeker voor een overstap van non Spring naar een Spring omgeving vind ik dat je niet gelijk alles moet vernieuwen.

Daar ben ik het me eens. Maar dat was ook niet de vraag van Momania.

Om het maar weer eens over de Spring boeg te gooien

Een ander belangrijk gevolg voor mij is dat ik op een andere manier tegen threading aan ben gaan kijken. Vroeger prakte ik het in de objecten, maar tegenwoordig trek ik het helemaal uit de objecten. In 1e instantie deed ik het alleen voor taken die gescheduled moesten worden, maar intussen doe ik het ook voor taken die continu moeten draaien. Het gevolg is dat je objecten veel eenvoudiger blijven, veel beter te testen zijn (aangezien ze geen eigen threads hebben) en ze zijn een stuk beter reusable (omdat ze minder monolytisch zijn).

vb

XML:

<bean id="fetcher"
          class="anchormen.kaloogaExp.fetcher.ThreadedFetcher">
        <!--  the channel where all downloaded pages are send to. -->
        <constructor-arg index="0" ref="fetcherOutputChannel"/>
        <!-- the workpool that is used to retrieve downloads from-->
        <constructor-arg index="1" ref="workPool"/>
        <!-- number of ms between requests from a single domain -->
        <constructor-arg index="2" value="500"/>
        <!-- the time in ms a domainpool is kicked to the db if it doesn`t get any new Downloads.-->
        <constructor-arg index="3" value="5000"/>
    </bean>

    <bean id="fetcherRepeater"
          class="org.jph.concurrent.repeater.StdRepeaterService"
          init-method="start"
          destroy-method="shutdown">

        <!-- number of threads -->
        <constructor-arg index="0" value="150"/>

        <!-- threadfactory -->
        <constructor-arg index="1">
            <bean class="org.jph.concurrent.StdThreadFactory">
                <!-- priority -->
                <constructor-arg index="0" value="1"/>
                <!-- name of the threadgroup -->
                <constructor-arg index="1" value="repeaters"/>
            </bean>
        </constructor-arg>

        <!-- the task to repeat -->
        <constructor-arg index="2">
            <bean class="org.jph.spring.scheduling.MethodInvokeRunnable">
                <constructor-arg>
                    <bean class="org.springframework.util.MethodInvoker">
                        <property name="targetObject" ref="fetcher"/>
                        <property name="targetMethod" value="run"/>
                    </bean>
                </constructor-arg>
            </bean>
        </constructor-arg>
    </bean>

De fetcher is een component met een run methode (kan je zien als een soortement van as). De repeater kan je zien als een groep met werkers die met zijn allen aan die as draaien.

[ Voor 94% gewijzigd door Alarmnummer op 31-10-2005 10:00 ]

Acties:

maandag 31 oktober 2005 10:25

iPhone 30! Bam!

Wat mij nu opvalt in je voorbeeld code is dat constructor params meegegeven worden op basis van positie (index). Is dat default of kan het ook op param name?

Natuurlijk kan je met comments wel duidelijk maken wat er gezet wordt, maar als je de param naam gewoon kan gebruiken, is het vaak al duidelijk genoeg wat je zet toch?

Gevaar zal dan wel weer zijn dat je niet zomaar je param names kan veranderen van je constructor natuurlijk.

Is dit gewoon een standaard van Spring of zie ik dat nu verkeerd?

Neem je whisky mee, is het te weinig... *zucht*

Acties:

maandag 31 oktober 2005 10:45

-= Tja =-

Topicstarter

momania schreef op maandag 31 oktober 2005 @ 10:18:
Wat mij nu opvalt in je voorbeeld code is dat constructor params meegegeven worden op basis van positie (index). Is dat default of kan het ook op param name?

Nope, want parameternamen zie je niet terug in de bytecode. Je kunt uiteraard wel met setters werken (maar ben ik in veel gevallen niet zo`n voorstander van).

Is dit gewoon een standaard van Spring of zie ik dat nu verkeerd?

Bij Spring werken ze zowel setter als constructor based. Voordeel aan een setter is dat het beter beschrijft wat het doet dan een constructor. Alleen vind ik een constructor in veel gevallen handiger doordat je later geen rekening hoeft te houden met de mogelijkheid dat een setter aangeroepen wordt.

En je plaatst er toch altijd wat commentaar bij (zelfs bij een setter).

Acties:

maandag 31 oktober 2005 11:08

Moderator Devschuur®

!litemod

In principe hoef je ook niet de index op te geven. Spring vergelijkt dan de types. Dit gaat echter fout wanneer er meerdere dezelfde types zijn, bij casten en als niet ambigu is welke constructor er gebruikt moet worden.

Ikzelf gerbuik trouwens vaak de setters. Hierbij geef je de propertynaam wel mee waardoor het een stuk duidelijker is. Nadeel hiervan is dat je bij een initializatie vaak al gegevens nodig hebt die pas worden geinjecteerd nadat het object aangemaakt is, dat je bepaalde properties moeilijk verplicht kunt stellen en dat je sommige properties eigenlijk 'write once read many times' wil hebben . Tot nu toe ben ik nog niet echt tegen dit soort dingen in de praktijk aangelopen, maar ik kan me goed voorstellen dat ze er zijn.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

Acties:

maandag 31 oktober 2005 11:12

iPhone 30! Bam!

Alarmnummer schreef op maandag 31 oktober 2005 @ 10:25:
[...]

Nope, want parameternamen zie je niet terug in de bytecode. Je kunt uiteraard wel met setters werken (maar ben ik in veel gevallen niet zo`n voorstander van).

[...]

Bij Spring werken ze zowel setter als constructor based. Voordeel aan een setter is dat het beter beschrijft wat het doet dan een constructor. Alleen vind ik een constructor in veel gevallen handiger doordat je later geen rekening hoeft te houden met de mogelijkheid dat een setter aangeroepen wordt.

En je plaatst er toch altijd wat commentaar bij (zelfs bij een setter).

Aha, zo dus.. duidelijk iig

Neem je whisky mee, is het te weinig... *zucht*

Acties:

maandag 31 oktober 2005 21:25

-= Tja =-

Topicstarter

momania schreef op maandag 31 oktober 2005 @ 11:08:
[...]

Aha, zo dus.. duidelijk iig

Het voordeel aan dit lijmen in Spring is dat je ook een enorme zooi java code kwijt raakt die eigelijk niet veel anders doet dan objecten opbouwen. Nu bouw je het hele systeem op in Spring en kun je veel meer concentreren op het bouwen van componenten. En je houdt beter overzicht over je systeem omdat je hele systeem opgebouwd wordt in een relatief klein aantal bestanden.

Acties:

misfire

Ik beschouw Spring echt als een evolutie in (enterprise) applicatie-ontwikkeling. Spring is uniek omdat het relatief technische innovaties als dependency injection en AOP aanbiedt in een toegankelijke en praktische vorm. Waar projecten als Avalon en AspectJ in het verleden faalde zie je dat nu toch de grote massa bereikt (gaat) worden, en dat is gewoon heel, heel belangrijk voor software ontwikkeling.

Een ander groot voordeel van Spring is dat ze zichzelf echt zien als een "Application Framework". Andere frameworks en API's concentreren zich vooral op het ontsluiten of aanbieden van infrastructuur (bijvoorbeeld JNDI, Servlets en Struts). Het nadeel daar van is dat je niet direct aan kunt sluiten op het probleemdomein waarin je de applicatie maakt, je hebt altijd een bepaalde afstand die je moet overbruggen met extra abstractielaagjes en glue-code. Spring lost dit heel mooi op met de meegeleverde glue-code en abstracties: dat is eigenlijk voor 90% van je applicatielogica al perfect. De afstand tussen Spring en je applicatielogica is heel klein. "Dood aan de in-house frameworks" is echt een hele goede reden om voor Spring te kiezen.

Het allermooiste van Spring vind ik wel dat je dankzij de gekozen aanpak die laatste 10% eigen customization kunt doen zonder vervelende trucs en vreemde concessies. Je eigen code en de Spring code hebben een level playing field en worden op exact dezelfde manier behandeld en geconfigureerd. Heel wat fijner dan ergens ineens een klasse extenden en ineens midden in de gory guts van een of ander framework gaan klooien. Een buitengewoon plezier bij-effect is backwards compatibility: Spring 1.2.5 is 99,999% backwards compatibel met Spring 1.0 beta 1.

Ik ben benieuwd of Spring op .NET een vlucht kan maken. Het .NET project lijkt de laatste maanden ook meer momentum te krijgen, en in .NET kent men bijna exact dezelfde problemen als in J2EE. De Spring oplossing is universeel, en ik denk dat het ook voor de .NET community fantastisch zou zijn als het ook daar voet aan de grond krijgt.

maandag 31 oktober 2005 21:29

Acties:

Verwijderd

kent iemand een tool die een bestaande beans xml omzet naar de nieuwe (verkorte) notatie? Zo niet dan schrijf ik hem zelf wel en is dat vast binnenkort wel op een of andere blog te vinden...

maandag 31 oktober 2005 21:37

Acties:

maandag 31 oktober 2005 21:55

-= Tja =-

Topicstarter

misfire schreef op maandag 31 oktober 2005 @ 21:25:
Ik beschouw Spring echt als een evolutie in (enterprise) applicatie-ontwikkeling. Spring is uniek omdat het relatief technische innovaties als dependency injection en AOP aanbiedt in een toegankelijke en praktische vorm. Waar projecten als Avalon en AspectJ in het verleden faalde zie je dat nu toch de grote massa bereikt (gaat) worden, en dat is gewoon heel, heel belangrijk voor software ontwikkeling.

Adrian Colyer (de man achter AspectJ) die gaat nu naar interface21 toe (het bedrijf achter Spring). En er komen binnenkort een paar leuke uitbreidingen (oa dependency injection in domain objecten) op basis van deze samenwerking.

http://www.aspectprogramm...5/09/joining_interfa.html
http://www.springframework.org/node/167

Persoonlijk ben ik niet zo gesharmeerd van Spring hun op proxies gebaseerde AOP toevoegingen. Meestal werkt het ok, maar zo nu en dan zit je toch even stevig achter je oren te krabben (vooral self problematiek is vervelend.. een call vanuit het binnenliggende object zal niet automatisch via de proxy verlopen.. en verder ben ik al vreemde dingen tegengekomen met classes waar niet alle methodes van te extenden waren).

Ik denk dat door AspectJ (en het feit dat je daar niet werkt op basis van een proxy maar echt de bytecode van een class aanpast) mijn liefde voor AOP weer zal aanwakkeren.

"Dood aan de in-house frameworks" is echt een hele goede reden om voor Spring te kiezen.

Een groot deel van allerlei eigen gebakken frutsels die kunnen door toedoen van Spring wel afgeschoten worden, alhoewel een je altijd wel wat bedrijfs specifieke functionaliteit over zult houden. Wij (waar ik werk) hebben ook een licht applicatieplatform (op basis van Spring) die ons dagelijks werk nog iets eenvoudiger maakt. Dus klein beetje blijf je wel houden, maar enorme lading meukcode kan idd weggegooid worden.

Het allermooiste van Spring vind ik wel dat je dankzij de gekozen aanpak die laatste 10% eigen customization kunt doen zonder vervelende trucs en vreemde concessies. Je eigen code en de Spring code hebben een level playing field en worden op exact dezelfde manier behandeld en geconfigureerd.

Wat ik het mooiste aan Spring vind is de eenvoud. Ik zet vrij complexe systemen in elkaar (met veel concurrency issues bv) en Spring maakt dit allemaal zo eenvoudig. Je houd gewoon veel beter overzicht en veel beter controle. En verder heb je gewoon veel minder nutteloze code.

[ Voor 21% gewijzigd door Alarmnummer op 31-10-2005 21:47 ]

Acties:

Verwijderd

Alarmnummer schreef op maandag 31 oktober 2005 @ 21:37:
Persoonlijk ben ik niet zo gesharmeerd van Spring hun op proxies gebaseerde AOP toevoegingen. Meestal werkt het ok, maar zo nu en dan zit je toch even stevig achter je oren te krabben (vooral self problematiek is vervelend.. een call vanuit het binnenliggende object zal niet automatisch via de proxy verlopen.. en verder ben ik al vreemde dingen tegengekomen met classes waar niet alle methodes van te extenden waren).

Ik denk dat door AspectJ (en het feit dat je daar niet werkt op basis van een proxy maar echt de bytecode van een class aanpast) mijn liefde voor AOP weer zal aanwakkeren.

Tsja hier is mijn mening nog niet geheel gevormd. Je zit met de beperking dat een klasse die geproxied wordt enkel wordt extend, en dat vinden final methodes niet zo fijn. Maar ik vind het ook niet een fijn idee om aspectj te moeten schrijven om pointcuts te realiseren. De configuratie moet niet teveel versnipperd raken. in dat geval maak ik liever een methode domweg niet final.

maandag 31 oktober 2005 22:01

Acties:

maandag 31 oktober 2005 22:13

-= Tja =-

Topicstarter

Verwijderd schreef op maandag 31 oktober 2005 @ 21:55:
[...]
Tsja hier is mijn mening nog niet geheel gevormd. Je zit met de beperking dat een klasse die geproxied wordt enkel wordt extend, en dat vinden final methodes niet zo fijn.

Dat is een probleem. Maar wat ik vooral erg vervelend vind is dat je geen foutmelding krijgt. Ik was aan het experimenteren om Wicket pages op te laten bouwen en een beetje aan het spelen met declaratieve security en bleef ik maar vreemde fouten houden. Bleek uiteindelijk wat final methodes aanwezig te zijn (in de pages) en ik kreeg daar geen foutmelding van.

Maar ik vind het ook niet een fijn idee om aspectj te moeten schrijven om pointcuts te realiseren.

In 99% van de gevallen zul jij nooit AspectJ code te hoeven schrijven (aangezien je meestal toch alleen maar transacties/security gebruikt van de AOP mogelijkheden).

De configuratie moet niet teveel versnipperd raken. in dat geval maak ik liever een methode domweg niet final.

1) die keuze heb je niet altijd.
2) AspectJ != configuratie. AspectJ is een programmeertaal die alles omvat wat java kan + daarop AOP toevoegd. En verder is AOP voor een oo developer, wat oo is voor een procedurele programmeur. Ohh.. polymorfisme.. dan weet je toch niet meer waar de logica staat? Maar hoe goed kan jij intussen met oo omgaan? Ik denk dat het in veel gevallen een kwestie van wennen is.

Acties:

Verwijderd

Alarmnummer schreef op maandag 31 oktober 2005 @ 22:01:
Dat is een probleem. Maar wat ik vooral erg vervelend vind is dat je geen foutmelding krijgt. Ik was aan het experimenteren om Wicket pages op te laten bouwen en een beetje aan het spelen met declaratieve security en bleef ik maar vreemde fouten houden. Bleek uiteindelijk wat final methodes aanwezig te zijn (in de pages) en ik kreeg daar geen foutmelding van.

Ja ik heb dergelijke problemen inderdaad gehad met MockClassControl, die gebruikt hetzelfde principe en je kunt zoeken tot je een ons weegt want een duidelijk melding krijg je niet.

Alarmnummer schreef op maandag 31 oktober 2005 @ 22:01:
1) die keuze heb je niet altijd.
2) AspectJ != configuratie. AspectJ is een programmeertaal die alles omvat wat java kan + daarop AOP toevoegd. En verder is AOP voor een oo developer, wat oo is voor een procedurele programmeur. Ohh.. polymorfisme.. dan weet je toch niet meer waar de logica staat? Maar hoe goed kan jij intussen met oo omgaan? Ik denk dat het in veel gevallen een kwestie van wennen is.

Ik weet wat aspectj is, waar het mij omgaat is dat het enkel een configuratie is. Ik wil namelijk, net zoals het nu geimplementeerd is, kunnen aangeven welke condities voor een methode gelden. En dat is puur configuratie. Wat ik dus niet wil is versnippering van dergelijke informatie, dus het moeten definieren van pointcuts in aspectj, alsmede in xml. Vandaar dat ik nog geen duidelijke mening heb over wat ik prettiger zou vinden. Maar we zien het wel ten tijde van de eerste implementaties...

dinsdag 1 november 2005 11:48

Acties:

woensdag 2 november 2005 14:25

-= Tja =-

Topicstarter

*kick*

Zijn er niet meer mensen die met Spring bezig zijn, of die in Spring geinteresseerd zijn? (of er slechte ervaringen mee hebben?)

Acties:

-FoX-

Carpe Diem!

Ik heb hele goede ervaringen met Spring in het algemeen, al is Spring meer dan een IoC container of MVC framework zoals velen nog steeds denken.

De 'inversion of control' houdt een goed design in de hand. Je moet niet allerhande truckjes gaan gebruiken om aan je referenties te komen... nee, de referenties komen naar jou :-)
Verder zorgt het Spring framework voor allerhande goede integraties met bestaande frameworks, technologieën zodat deze perfect op elkaar te lijmen zijn. Ik denk hier bvb aan de ondersteuning naar Hibernate toe, of JDBC in het algemeen.

Maar ik wil het nu even niet hebben over de algemene Spring zaken, maar mijn eerste ervaringen wat meer toelichten betreffende het Acegi Security System for Spring.

Acegi Security voorziet in 2 managers die voorzien in het beveiligen van je applicatie. De AuthenticationManager bepaalt de identiteit van de gebruiker en de AccessDecisionManager laat de gebruiker enkel toe tot de resources die in zijn profiel passen.

De authenticationManager delegeert de verantwoordelijkheid voor de authenticatie naar één of meerdere authenticatie providers (Dao, Jaas, Ldap, ...).

Het is mogelijk om de wachtwoorden, die in de db opgeslagen worden, te voorzien van een encryptie zodat ze niet meer leesbaar zijn vanuit de db zelf. Default worden ze ongeëncrypteerd opgeslagen. Er kan gebruik gemaakt worden van 3 verschillende encoders: PlaintextPasswordEncoder (default), Md5PasswordEncoder, ShaPasswordEncoder.
Het is ook nodig om een salt source te definiëren voor de encoder. Salt kan gezien worden als een encryptie sleutel. Acegi voorziet in 2 soorten salts: ReflectionSaltSource (unieke salt per user, gebaseerd op bvb de username) en SystemWideSaltSource (dezelfde salt voor alle users).

Als een gebruiker zich kenbaar heeft gemaakt aan het systeem en de toegang verkregen heeft, komt de Decision manager in actie om de gebruiker enkel toe te laten tot de resources die in zijn profiel past.

Dit security framework zit op zich heel goed en logisch in elkaar al denk ik dat er toch een aantal nadelen verbonden zijn aan de zovele voordelen.
Eén van die nadelen is het feit dat er in de laatste versie's nogal wat grotere wijzigingen doorgevoerd werden aan de triviale componenten waardoor de goede documentatie in bvb het Spring in Action boek niet overal toepasbaar is aangezien er hier nog gebruikt werd gemaakt van de 0.7.0 versie (bvb de complexere ACL). De documentatie op zich lijkt me wel vrij compleet, maar is nogal abstract geschreven. Op zich geen probleem, als je zelf een beetje de moeite wil doen om de bestaande example applicaties eens te overlopen.

Tegen het einde van het jaar zou v1.0 klaar moeten zijn, al zullen er geen grote interne wijzigingen meer plaatsvinden. Het product zelf is vrij compleet, al laat het versienummer misschien iets anders vermoeden.

Maar verder hier een zeer tevreden gebruiker van het Spring framework

offtopic:
Dit in tegenstelling tot Hibernate, waar ik geregeld nog eens mee in de knoop lig, en de leercurve voor Spring lag ook een stuk lager

woensdag 2 november 2005 14:35

Acties:

woensdag 2 november 2005 14:48

-= Tja =-

Topicstarter

Het probleem aan hibernate is dat het forum ronduit kut is en dat documentatie bepaalde problemen (vooral cascade problematiek) niet goed uitlegd. Hibernate in Action helpt al een heel eind, maar er zitten ook nog steeds gaten in mijn Hibernate kennis waarbij ik geen flauw idee heb hoe deze vragen beantwoord kunnen worden.

Acties: