[Java] Iemand die EJB3 met plezier gebruikt?

zondag 31 december 2006 19:56

Topicstarter

Cuball schreef op zondag 31 december 2006 @ 18:08:
[...]
Misschien heb je wel gelijk in het feit dat Spring 2 op het eerste zicht wat complexer lijkt voor developers die er voor het eerst in contact mee komen

Maar dat is toch juist 1 van de definities van 'zwaar'?

Of een framework nou 100MB of 300MB op disk is maakt helemaal niets uit als je toch een 120GB disk hebt.

Ik heb noch ervaring met spring2 noch met ejb3. Als ik nu (snel) wat "getting started with" dingen doorlees dan denk ik momenteel bij spring toch wel dat het een veel omvattend en complex iets is. Bij EJB3 heb ik nu eerder het gevoel dat het wel behapbaar is. Of dit veranderd als je er concreet dag in dag uit mee werkt weet ik natuurlijk niet.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

maandag 1 januari 2007 16:05

Ik heb met EJB3 wel wat gedaan, maar nog geen serieus project. Er zijn veel dingen handiger geworden. Voor EJBs had je vroeger tool-support nodig, dat is nu helemaal weg door bepaalde details te versimpelen en in annotaties te stoppen. Dat entity-beans zijn gekilled ipv JPA is een goede zaak. Helaas is JPA wel enigszins beperkt in de mogelijkheden, dus zul je voor een paar specifieke dingen wel terug moeten grijpen naar vendor-specifieke API's.

EJB's blijven echter relatief nog wel complex. De spec is er niet dunner op geworden, en de meeste spelregels van vroeger mbt lifecycle, remoting, transactie en threading management blijven van kracht. Op een bepaalde manier is dit een voordeel van EJB's, maar je moet nog steeds weten dat een EJB (nog steeds) niet zomaar een pojo is. Dat stuk complexiteit zul je altijd houden, dat is gewoon een consequentie van het hele idee van "enterprise" componenten.

Spring en EJB vergelijken is een beetje appels en peren. EJB is enterprise component framework, Spring is een soort glue-code framework waarmee je makkelijk verbindingen kunt maken tussen populaire frameworks en je applicatie zonder dat je hiervoor boilerplate code hoeft te schrijven. Of je Spring of EJB3 inzet zijn denk ik verschillende keuzes,

Op zich vind ik het opvallend dat je Spring v2 moeilijker vindt, het thema van die release was namelijk "ease of development". Ook in Spring 2 zitten nieuwe handige dingen waarmee je de dingen die heel vaak gedaan moeten worden makkelijker en sneller op kunt zetten. Het probleem met Spring vind ik tegenwoordig dat ze echt ongeveer alles bouwen, en Spring inzetten als trademark om al die frameworks te pushen. Het pick & choose idee van de Spring "supermarket" wordt hierdoor een beetje vervuild: je weet niet waar je moet beginnen en wat je moet gebruiken om aan "Spring" te doen.

Acties:

maandag 1 januari 2007 21:07

Design-by-buzzword fanatic

misfire schreef op zondag 31 december 2006 @ 19:56:
Ik heb met EJB3 wel wat gedaan, maar nog geen serieus project. Er zijn veel dingen handiger geworden. Voor EJBs had je vroeger tool-support nodig, dat is nu helemaal weg door bepaalde details te versimpelen en in annotaties te stoppen. Dat entity-beans zijn gekilled ipv JPA is een goede zaak. Helaas is JPA wel enigszins beperkt in de mogelijkheden, dus zul je voor een paar specifieke dingen wel terug moeten grijpen naar vendor-specifieke API's.

Entity beans zijn niet gekilled. Eén van de dingen van de EJB 3.0 spec is dat het helemaal backwards compatible is met 2.1. Als je graag entity beans gebruikt, of je hebt al een complete applicatie gebouwd met entity beans, dan kun je die nog prima gebruiken. Voor nieuwbouw zal echter niemand voor entity beans kiezen, maar voor de versimpelde Hibernate aanpak van de JPA.

Bovendien is JPA alleen maar een spec, je kunt prima Hibernate als persistence provider gebruiken. (en dus Hibernates geavanceerdere features, maar goed, dat gaat ten koste van de portabiliteit)

EJB's blijven echter relatief nog wel complex. De spec is er niet dunner op geworden, en de meeste spelregels van vroeger mbt lifecycle, remoting, transactie en threading management blijven van kracht. Op een bepaalde manier is dit een voordeel van EJB's, maar je moet nog steeds weten dat een EJB (nog steeds) niet zomaar een pojo is. Dat stuk complexiteit zul je altijd houden, dat is gewoon een consequentie van het hele idee van "enterprise" componenten.

Ik heb een paar weken geleden het bèta examen van SCBCD 5.0 gemaakt. Daar merk je heel duidelijk dat de onderliggende architectuur en concepten precies gelijk zijn gebleven. Transactiemanagement en zo zijn nog exact hetzelfde. Complex dus.

Maar... Het leuke aan EJB 3.0 proggen is dat je annotaties hebt en goede defaults. Je hebt geen deployment descriptor nodig. De appserver zoekt zelf wel naar de juiste bestanden in je applicatie. Dependency injection is nog makkelijker dan in Spring. Je mikt gewoon @EJB voor de property en de container zoekt het zelf allemaal wel uit. Binnen redelijke grenzen natuurlijk, daarna moet je ff iets bij proggen.

Spring en EJB vergelijken is een beetje appels en peren. EJB is enterprise component framework, Spring is een soort glue-code framework waarmee je makkelijk verbindingen kunt maken tussen populaire frameworks en je applicatie zonder dat je hiervoor boilerplate code hoeft te schrijven. Of je Spring of EJB3 inzet zijn denk ik verschillende keuzes,

Maar vind je dat de keuze voor één van de twee de andere uitsluit? In EJB 2.1 is Spring fijn, omdat je dat bijvoorbeeld de toegang tot je beans kan laten verzorgen, zodat je niet als een idioot CreateExceptions en RemoteExceptions aan het catchen bent die 9 van de 10 keer toch niet voorkomen en anders is het vaak een programmeer/deploy fout.
Ook heeft Spring een superieure Hibernate integratie.

Maar, als je EJB 3.0 gebruikt, zal je waarschijnlijk de JPA je DB access laten regelen en heb je daar Spring al niet voor nodig. Bovendien zijn je beans zelf ook veel handelbaarder geworden en wordt het voordeel van Spring nog kleiner.

Iemand die voordelen van Spring ziet in een EJB 3.0 applicatie?

Mij lijkt trouwens JBoss Seam bruut. JSF, EJB 3.0 en JBPM op een mooie manier geëntegreerd. Wat wil je nog meer.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

dinsdag 2 januari 2007 08:04

Entity Beans zijn inderdaad alleen nog in de 2.1 smaak te krijgen. De 2.1 backwards compatibiliteit in de EE 5 specs vind ik overigens een beetje een mixed blessing. Het maakt het aan de ene kant makkelijker om te migreren, maar aan de andere kant moeilijker om een EE 5 compliant appserver te bouwen (vooral voor nieuwe spelers op de markt). Wat mij betreft had 1.4 compatibiliteit ook best een vendorspecifieke feature kunnen zijn.

Bovendien is JPA alleen maar een spec, je kunt prima Hibernate als persistence provider gebruiken. (en dus Hibernates geavanceerdere features, maar goed, dat gaat ten koste van de portabiliteit)

Precies en daarom is het jammer dat je met JPA een aantal basisdingen wel kunt, maar dat er geen dingen geregeld zijn voor bijvoorbeeld een Criteria API enz. In de praktijk zul je voor veel applicaties altijd moeten mixen tussen jpa code voor het standaardwerk en Hibernate/TopLink/Kodo code voor de geavanceerde trucs. 100% portable is meestal echter ook niet echt een vereiste, en met JPA is in ieder geval de basiskennis nu portibable, en dat is al heel wat.

Maar... Het leuke aan EJB 3.0 proggen is dat je annotaties hebt en goede defaults. Je hebt geen deployment descriptor nodig. De appserver zoekt zelf wel naar de juiste bestanden in je applicatie. Dependency injection is nog makkelijker dan in Spring. Je mikt gewoon @EJB voor de property en de container zoekt het zelf allemaal wel uit. Binnen redelijke grenzen natuurlijk, daarna moet je ff iets bij proggen.

Dat hoor ik wel vaker, maar Java EE DI is duidelijk anders als Spring. Java EE DI beperkt is tot "enterprise resources" voor zowel geinjecteerde waardes als de objecten waarin injecteerd wordt. Zo maar een String setting in een pojo injecteren lukt dus bijvoorbeeld niet. Bij Spring kun je alles injecteren, in ieder willekeurig object, niet alleen in EJB's en Servlets. Dat neemt niet weg dat Java EE DI een elegant systeem is, zeker voor dependency injection fans als ik.

De bekendste vorm van Spring DI is de XML config met named references. In Spring is echter ook de "autowire" optie waarmee objecten op basis van type automagisch worden injecteerd. Spring is ook met een annotation based configuration experiment bezig voor de mensen die echt geen XML meer willen kloppen.

Maar vind je dat de keuze voor één van de twee de andere uitsluit?

Nee dat vind ik dus niet, omdat het verschillende frameworks zijn voor andere problemen. Waar je wel gelijk in hebt is dat je voor Java EE 5 op een aantal onderdelen geen boilerplate code meer hoeft te schrijven, en dus ook geen Spring meer nodig hebt om je daar tegen te beschermen. Maar Spring kon en kun je ook op andere onderdelen en manieren inzetten in je applicatie. Het is maar net hoe ver je kunt/wilt gaan met aan de ene kant alles in een EJB stoppen, en aan de andere kant alles injecteren en configureerbaar maken.

Mij lijkt trouwens JBoss Seam bruut. JSF, EJB 3.0 en JBPM op een mooie manier geëntegreerd. Wat wil je nog meer.

Een JSR voor Seam.

Even serieus, ik vind het ook veelbelovend, en zowieso eindelijk een initiatief die voor the "big picture" gaat. Het is voor mij nog wel onduidelijk hoe "tweakable" Seam is. Het probleem met een application framework is dat je altijd vervelende uitzonderingen hebt die niet in het framework zitten of zelfs niet ondersteund worden. Het framework moet je dus per stap kunnen aanpassen zodat je zelf nog gedrag kunt overrulen. In de eerste previews van Seam kon je niet zo ver van het beslagen pad afwijken, maar nu schijnt dit al flink verbeterd te zijn. Het staat ook op mijn lijstje van dingen om mee te hobbyen.

Acties:

dinsdag 2 januari 2007 19:58

Design-by-buzzword fanatic

misfire schreef op maandag 01 januari 2007 @ 21:07:
Entity Beans zijn inderdaad alleen nog in de 2.1 smaak te krijgen. De 2.1 backwards compatibiliteit in de EE 5 specs vind ik overigens een beetje een mixed blessing. Het maakt het aan de ene kant makkelijker om te migreren, maar aan de andere kant moeilijker om een EE 5 compliant appserver te bouwen (vooral voor nieuwe spelers op de markt). Wat mij betreft had 1.4 compatibiliteit ook best een vendorspecifieke feature kunnen zijn.

Iets als backwards compatibility is bijna niet vendor specific te maken. Wat ze wel zouden kunnen doen, is het optioneel maken met regels voor als je het wél zou willen implementeren. Maar goed, de grote spelers draaien al een tijdje mee en hebben op dit gebied niet veel problemen volgens mij, vooral omdat de onderliggende EJB architectuur niet erg veranderd is.

Precies en daarom is het jammer dat je met JPA een aantal basisdingen wel kunt, maar dat er geen dingen geregeld zijn voor bijvoorbeeld een Criteria API enz. In de praktijk zul je voor veel applicaties altijd moeten mixen tussen jpa code voor het standaardwerk en Hibernate/TopLink/Kodo code voor de geavanceerde trucs. 100% portable is meestal echter ook niet echt een vereiste, en met JPA is in ieder geval de basiskennis nu portibable, en dat is al heel wat.

Tja, Criteria had ik eigenlijk ook wel op gehoopt, maar goed, dat zal wel niet in TopLink of Kodo gezeten hebben.

Dat hoor ik wel vaker, maar Java EE DI is duidelijk anders als Spring. Java EE DI beperkt is tot "enterprise resources" voor zowel geinjecteerde waardes als de objecten waarin injecteerd wordt. Zo maar een String setting in een pojo injecteren lukt dus bijvoorbeeld niet. Bij Spring kun je alles injecteren, in ieder willekeurig object, niet alleen in EJB's en Servlets. Dat neemt niet weg dat Java EE DI een elegant systeem is, zeker voor dependency injection fans als ik. De bekendste vorm van Spring DI is de XML config met named references. In Spring is echter ook de "autowire" optie waarmee objecten op basis van type automagisch worden injecteerd. Spring is ook met een annotation based configuration experiment bezig voor de mensen die echt geen XML meer willen kloppen.

Je kunt in EJB 3.0 ook simpele types injecteren. Dit komt uit de core spec:

Java:

@Stateless public class EmployeeServiceBean implements EmployeeService {
    ...
    // The maximum number of tax exemptions, configured by Deployer
    @Resource int maxExemptions;
    // The minimum number of tax exemptions, configured by Deployer
    @Resource int minExemptions;
    public void setTaxInfo(int numberOfExemptions,...) throws InvalidNumberOfExemptionsException {
        ...
        // Use the environment entries to customize business logic.
        if (numberOfExemptions > maxExemptions || numberOfExemptions < minExemptions)
            throw new InvalidNumberOfExemptionsException();
    }
}

De deployment descriptor code voor deze klasse: (ook uit de spec)

XML:

<enterprise-beans>
  <session>
    ...
    <ejb-name>EmployeeService</ejb-name>
    <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class>
    ...
    <env-entry>
      <env-entry-name>
        com.wombat.empl.EmployeeService/maxExemptions
      </env-entry-name>
      <env-entry-type>java.lang.Integer</env-entry-type>
      <env-entry-value>15</env-entry-value>
      <injection-target>
        <injection-target-class>
          com.wombat.empl.EmployeeServiceBean
        </injection-target-class>
        <injection-target-name>
          maxExemptions
        </injection-target-name>
      </injection-target>
    </env-entry>
    <env-entry>
      <env-entry-name>
        com.wombat.empl.EmployeeService/minExemptions
      </env-entry-name>
      <env-entry-type>java.lang.Integer</env-entry-type>
      <env-entry-value>1</env-entry-value>
      <injection-target>
        <injection-target-class>
          com.wombat.empl.EmployeeServiceBean
        </injection-target-class>
        <injection-target-name>
          minExemptions
        </injection-target-name>
      </injection-target>
    </env-entry>
    ...
  </session>
</enterprise-beans>

En je kunt eventueel zo een default aangeven:

Java:

1	@Resource int maxExemptions = 4; // defaults to 4

Ik geef meteen toe, die XML is vrij verboos, maar goed, het werkt voor de rest wel aardig.

Nee dat vind ik dus niet, omdat het verschillende frameworks zijn voor andere problemen. Waar je wel gelijk in hebt is dat je voor Java EE 5 op een aantal onderdelen geen boilerplate code meer hoeft te schrijven, en dus ook geen Spring meer nodig hebt om je daar tegen te beschermen. Maar Spring kon en kun je ook op andere onderdelen en manieren inzetten in je applicatie. Het is maar net hoe ver je kunt/wilt gaan met aan de ene kant alles in een EJB stoppen, en aan de andere kant alles injecteren en configureerbaar maken.

Idd, maar ik doel dus op dat nu volgens mij een eenduidige oplossing steeds gemakkelijker wordt. Waar je bij 1.4 nog naar open source frameworks MOEST uitwijken, kun je nu een 100% volgens spec een volwaardige applicatie neerzetten. Als in, een JSF, EJB 3.0, JPS stack.

Een JSR voor Seam. Even serieus, ik vind het ook veelbelovend, en zowieso eindelijk een initiatief die voor the "big picture" gaat. Het is voor mij nog wel onduidelijk hoe "tweakable" Seam is. Het probleem met een application framework is dat je altijd vervelende uitzonderingen hebt die niet in het framework zitten of zelfs niet ondersteund worden. Het framework moet je dus per stap kunnen aanpassen zodat je zelf nog gedrag kunt overrulen. In de eerste previews van Seam kon je niet zo ver van het beslagen pad afwijken, maar nu schijnt dit al flink verbeterd te zijn. Het staat ook op mijn lijstje van dingen om mee te hobbyen.

Ik denk dat dat ook nog wel beter wordt, in mijn ervaring is het meestal het probleem van een jong framework, dat het niet erg flexibel is omdat alles in het teken staat van het opzetten van een goede architectuur en API. Ook de documentatie vind ik op het eerste gezicht (zoals JBoss betaamt

) niet echt denderend.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

dinsdag 2 januari 2007 20:16

Topicstarter

JKVA schreef op dinsdag 02 januari 2007 @ 08:04:
Ik geef meteen toe, die XML is vrij verboos, maar goed, het werkt voor de rest wel aardig.

Inderdaad, een beetje tegen haar eigen aanbevelingen uit de J2EE/Java EE turtorial in, is men bij Sun opeens heel erg tegen attributen in XML. Heel veel zaken die zowel logisch als practisch een attribuut zijn, worden opeens elementen. Je ziet dat ook bij bijvoorbeeld JSF. Hele lappen XML en geen attribuut te bespeuren.

Bij de EJB XML zie je eigenlijk ook al dat sommige elementen eigenlijk logisch attributen zijn: men gaat ze prefixen met de naam van het parent element. Waarschijnlijk is er een of andere tech lead aangenomen die een stylistische afkeer tegen attributen heeft, net zoals sommige mensen b.v. een afkeer hebben tegen table elementen in HTML, en ook dingen die logisch een table -zijn- door divjes gaan vervangen.

XML:

<enterprise-beans> 
  <session> 
    ... 
    <ejb-name>EmployeeService</ejb-name> 
    <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class> 
    ... 
    <env-entry 
         name="com.wombat.empl.EmployeeService/maxExemptions" 
         type="java.lang.Integer"
         value="15"
     >      
         <injection-target
             class="com.wombat.empl.EmployeeServiceBean"
             name="maxExemptions"
          />      
    </env-entry> 
        ... 
  </session> 
</enterprise-beans>

Door alleen die eerste injection elementen direct in attributen om te zetten wordt het imho al veel leesbaarder.

Idd, maar ik doel dus op dat nu volgens mij een eenduidige oplossing steeds gemakkelijker wordt. Waar je bij 1.4 nog naar open source frameworks MOEST uitwijken, kun je nu een 100% volgens spec een volwaardige applicatie neerzetten. Als in, een JSF, EJB 3.0, JPS stack.

Dat is ook wat ik eerder bedoelde. Niet dat Spring hetzelfde is als EJB, maar dat je met EJB3 Spring zelf minder of niet nodig hebt. Spring MVC is trouwens wel een uitzondering, die concureerd wel direct met Java EE zelf, maar ook daar geldt dat je met het JSF onderdeel van Java EE geen Spring (MVC) meer nodig hebt.

Een JSR voor Seam

Die heb je toch min of meer in de vorm van die web beans jsr (jsr 299)?

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

dinsdag 2 januari 2007 21:20

Design-by-buzzword fanatic

Als we toch aan het opschonen zijn:

XML:

<enterprise-beans> 
  <session> 
    <ejb-name>EmployeeService</ejb-name> 
    <ejb-class>com.wombat.empl.EmployeeServiceBean</ejb-class> 
    <resource value="15" type="java.lang.Integer" target="maxExemptions" />
  </session> 
</enterprise-beans>

Die class in <injection-target> is toch redundant dus die mikken we mooi weg. Het feit dat ie in dat subelement staat, geeft toch een te kleine scope aan dat verder hergebruik niet mogelijk is. (denk ik

) Met nog één attribuut over, is een dedicated element ook zinloos, dus die verplaatsen we ook. Waarom je zo'n env-entry een naam zou willen geven, geen idee wat het nut daarvan is, dus die mikken we er ook mooi uit.

Volgens mij heb je zo op een gemakkelijkere manier dezelfde functionaliteit. Iemand argumenten waarom ze voor die 'moeilijke' oplossing gekozen hebben? Het zal tenslotte wel nut hebben...

flowerp schreef op dinsdag 02 januari 2007 @ 19:58:
[...]
Dat is ook wat ik eerder bedoelde. Niet dat Spring hetzelfde is als EJB, maar dat je met EJB3 Spring zelf minder of niet nodig hebt. Spring MVC is trouwens wel een uitzondering, die concureerd wel direct met Java EE zelf, maar ook daar geldt dat je met het JSF onderdeel van Java EE geen Spring (MVC) meer nodig hebt.
[...]

Ik moet toegeven, ik ken niet de details van Spring MVC, maar uit de ervaring van wat ik ermee gedaan heb, concludeer ik momenteel dat het zwaaaar onderdoet voor JSF ( + Facelets + ADF en co). Iedereen loopt overal wel op JSF te flamen, maar los van de leercurve vind ik het een ijzersterk framework.

Die heb je toch min of meer in de vorm van die web beans jsr (jsr 299)?

Heb je daar al iets van gezien toevallig? Seam oogt namelijk bruutjes.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

dinsdag 2 januari 2007 23:21

Dat je met EJB3 ook dat primitives kunt injecteren is wel handig, dat wist ik nog niet.

En JSR 299 is ook nieuw voor me, is inderdaad een JSR voor de basis van Seam. Helaas hangt er wel een stevige tijdslijn aan de JSR: 1.0 Final pas op april 2008. Maar goed ik hoop dat ze desondanks toch echt iets kunnen bereiken op dit gebied.

JSF heeft inderdaad alles out of the box wat Spring MVC ook heeft (alleen integreert het bij JSF beter). Als je JSF gebruikt dan kun je mvc beter niet gebruiken.

Ik ben het helemaal eens met de notie dat door de verbeteringen in Java EE 5 Spring op sommige onderdelen niets meer hoeft toe te voegen, en dat is volgens mij alleen maar positief. Het blijft echter een simpel "lightweight" beansfactory model vs een "heavyweight" managed EJB container met al zijn regels. Mijn (wellicht naïeve) idee is dát het grote verschil: niet meer alles per sé in een EJB. Maar misschien was men EJB's alleen moe omdat er wat meer getypt moest worden en was dat het enige probleem...

Acties:

woensdag 3 januari 2007 07:53

Topicstarter

JKVA schreef op dinsdag 02 januari 2007 @ 20:16:
Als we toch aan het opschonen zijn:
Die class in <injection-target> is toch redundant dus die mikken we mooi weg. Het feit dat ie in dat subelement staat, geeft toch een te kleine scope aan dat verder hergebruik niet mogelijk is. (denk ik ) Met nog één attribuut over, is een dedicated element ook zinloos, dus die verplaatsen we ook.

't kan zelfs nog eentje korter in veel gevallen: die type kan er ook uit, want je kunt de method opzoeken en gewoon zien wat het type moet zijn.

Volgens mij heb je zo op een gemakkelijkere manier dezelfde functionaliteit. Iemand argumenten waarom ze voor die 'moeilijke' oplossing gekozen hebben? Het zal tenslotte wel nut hebben...

Inderdaad. Als je alleen maar attributen gaat gebruiken dan blijft de eigenlijke structuur grotendeels hetzelfde. Een uitzondering is mischien value. Als je dat als attribuut neemt dan kan het alleen een string literal zijn. Maak je daar echter een element van dan kun je ook bijvoorbeeld een Map of List van values specificeren (zoals in JSF).

Maar zelfs dan kun je het al eenvoudiger maken door voor de simpele gevallen een attribuut te gebruiken, en dan alternatief een element. Ook dat principe kent Java EE al van de taglibs ( attribuut vs <jsp:attribute> element).

Wat betreft de andere 'moeilijke' oplossingen, gegeven de originele structuur zou je kunnen bedenken dat je 1 gedefineerde value in meerdere beans injecteerd. Deze eene gedefineerde value zou je inderdaad een naam willen geven als het om een "well-known business constant" gaat. Geen idee of dat zo is, maar wie weet?

XML:

<env-entry  
         name="CompanyProfitMargin"  
         type="java.lang.Integer" 
         value="15" 
     >       
         <injection-target 
             class="com.wombat.subscription.RulesOverview" 
             name="profitMargin" 
          /> 
         <injection-target 
             class="com.wombat.order.OrderProcessing" 
             name="deductPercentage" 
          />      
      
    </env-entry>

In dit geval defineer je een globale constante en injecteer je die meteen in 2 beans. Mischien dat deze constante ook op de een of andere manier zo direct opvraagbaar is uit een ejb-context object. (zoals je dus ook constanten uit web.xml kunt opvragen).

Iedereen loopt overal wel op JSF te flamen, maar los van de leercurve vind ik het een ijzersterk framework.

Ben ik het helemaal mee eens. Wat ik merk is dat een gedeelte van de kritiek komt van mensen die gewoon alles van Sun afkraken omdat het via een spec tot stand komt, en voor hen een spec automatisch gelijk staat aan zwaar, en zwaar dan weer automatisch gelijk staat aan slecht. Een ander gedeelte van de kritiek komt van mensen die ooit eens 1 van de allereerste preview releases van de RI heeft bekeken. Daar zaten inderdaad veel bugs in, en de beschikbare componenten waren bijzonder karig.

Op dit moment is JSF officieel uit, en komt de componenten markt goed op gang. Sun zelf levert eigenlijk in de spec niet echt indrukwekkende componenten mee; dat is expliciet gedaan. Als je naar ADF kijkt, of zelfs maar naar Tomahawk of als je wellicht zelf componenten maakt, dan zie je dat JSF toch wel een zeer knap fundament is.

Heb je daar al iets van gezien toevallig? Seam oogt namelijk bruutjes.

Seam is zeker iets wat ik ook in de gaten hou. Zoals de omschrijving zelf al aangeeft is het de 'zoom' tussen EJB en JSF. Wat ik er voornamelijk mooi aan vind is de conversational scope; een scope die groter is als de request scope, maar kleiner als de session scope. Een op papier perfecte oplossing voor back-button, double commit en refresh problemen in web apps.

Voordat dit officieel in Java EE (6?) komt zijn we nog wel even verder. Helemaal als je bedenkt dat na het uitkomen van de spec je in de regel ook nog eens minstens een jaar mag wachten totdat jouw favoriete app server het implementeerd.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

donderdag 4 januari 2007 08:55

Design-by-buzzword fanatic

flowerp schreef op dinsdag 02 januari 2007 @ 23:21:
[...]
't kan zelfs nog eentje korter in veel gevallen: die type kan er ook uit, want je kunt de method opzoeken en gewoon zien wat het type moet zijn.
[...]

Jup, die kan dan mooi optioneel worden.

Inderdaad. Als je alleen maar attributen gaat gebruiken dan blijft de eigenlijke structuur grotendeels hetzelfde. Een uitzondering is mischien value. Als je dat als attribuut neemt dan kan het alleen een string literal zijn. Maak je daar echter een element van dan kun je ook bijvoorbeeld een Map of List van values specificeren (zoals in JSF).

Idd, dat is waar. En als het in JSF werkt, zou het in EJB ook moeten werken. Behalve dat er in EJB misschien meer mogelijkheden voorzien zijn door de expert group o.i.d. Ik heb namelijk ergens de indruk dat we te simpel denken.

Wat betreft de andere 'moeilijke' oplossingen, gegeven de originele structuur zou je kunnen bedenken dat je 1 gedefineerde value in meerdere beans injecteerd. Deze eene gedefineerde value zou je inderdaad een naam willen geven als het om een "well-known business constant" gaat. Geen idee of dat zo is, maar wie weet?
XML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<env-entry  
         name="CompanyProfitMargin"  
         type="java.lang.Integer" 
         value="15" 
     >       
         <injection-target 
             class="com.wombat.subscription.RulesOverview" 
             name="profitMargin" 
          /> 
         <injection-target 
             class="com.wombat.order.OrderProcessing" 
             name="deductPercentage" 
          />      
      
    </env-entry>  
In dit geval defineer je een globale constante en injecteer je die meteen in 2 beans. Mischien dat deze constante ook op de een of andere manier zo direct opvraagbaar is uit een ejb-context object. (zoals je dus ook constanten uit web.xml kunt opvragen).

En dat bedoelde ik in de vorige post met een te kleine scope. Ik kan me niet voorstellen dat het logisch is dat je binnen een bean iets definieert (soort lokale scope), maar het eigenlijk een soort globale scope krijgt.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

donderdag 4 januari 2007 09:48

Design-by-buzzword fanatic

Wat overigens ook leuk is aan EJB 3.0, is dat je nu echt supermakkelijk een web service in elkaar draait. Gewoon ff de annotatie @WebService erboven en de container genereert alles lekker zelf.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

vrijdag 5 januari 2007 08:44

-= Tja =-

JKVA schreef op donderdag 04 januari 2007 @ 08:55:
Wat overigens ook leuk is aan EJB 3.0, is dat je nu echt supermakkelijk een web service in elkaar draait. Gewoon ff de annotatie @WebService erboven en de container genereert alles lekker zelf.

Het is verstandiger om te beginnen met je WSDL en daaruit de implementatie te laten volgen, ipv het andersom te doen. Hierdoor is je WSDL een stuk minder stabiel, en dat is precies hetgeen een webservice nodig heeft. Ik ben daarom dus niet een groot voorstander van deze aanpak (alhoewel het wel tijd kan besparen op korte termijn).

Acties:

vrijdag 5 januari 2007 09:25

Design-by-buzzword fanatic

Alarmnummer schreef op donderdag 04 januari 2007 @ 09:48:
[...]

Het is verstandiger om te beginnen met je WSDL en daaruit de implementatie te laten volgen, ipv het andersom te doen. Hierdoor is je WSDL een stuk minder stabiel, en dat is precies hetgeen een webservice nodig heeft. Ik ben daarom dus niet een groot voorstander van deze aanpak (alhoewel het wel tijd kan besparen op korte termijn).

Daar ben ik het helemaal mee eens. Op mijn huidige project ben ik ook met opzet zo bezig, maar je merkt wel dat die aanpak veel meer tijd kost. Dat valt me wel op.

Maar goed, dan maar wsdl2java. Dat scheelt alvast weer tijd...

Fat Pizza's pizza, they are big and they are cheezy

Acties:

ari3

Ik bouw momenteel een commerciële applicatie met EJB3 op JBoss. De ervaring is overwegend positief tot nu toe.

Wat ik wel een stap terug vind in EJB3 is de manier waarop named queries zijn geïmplementeerd. Vanuit je code refereer je aan een named query met een String "findX" waardoor een compile time consistentie check niet mogelijk is. Veelal zie je type-fouten pas bij het uitvoeren van de query pas aan het licht komen, dus pas na een build en deploy cycle.

Bij EJB2.x werden de finders vóór iedere build gegenereerd en kon je gewoon een method find() aanroepen. Hierdoor was óf alles consistent óf je kreeg een compileerfout.

"Kill one man, and you are a murderer. Kill millions of men, and you are a conqueror. Kill them all, and you are a god." -- Jean Rostand

vrijdag 5 januari 2007 15:19

Acties:

vrijdag 5 januari 2007 16:01

Design-by-buzzword fanatic

ari3 schreef op vrijdag 05 januari 2007 @ 09:25:
Ik bouw momenteel een commerciële applicatie met EJB3 op JBoss. De ervaring is overwegend positief tot nu toe.

Wat ik wel een stap terug vind in EJB3 is de manier waarop named queries zijn geïmplementeerd. Vanuit je code refereer je aan een named query met een String "findX" waardoor een compile time consistentie check niet mogelijk is. Veelal zie je type-fouten pas bij het uitvoeren van de query pas aan het licht komen, dus pas na een build en deploy cycle.

Bij EJB2.x werden de finders vóór iedere build gegenereerd en kon je gewoon een method find() aanroepen. Hierdoor was óf alles consistent óf je kreeg een compileerfout.

Tsja, dat is de manier van werken die ze van Hibernate overgenomen hebben. In Hibernate HQL type je in feite ook alles in één grote string die tijdens runtime geparsed wordt.

Je hebt naast de queries wel natuurlijk gewoon de opties in de EntityManager:
- find(class, key);
- getReference(class, key);

Waarbij bij 'find' het record niet in de DB hoeft te bestaan en hij null returned. Bij 'getReference' moet het record wel bestaan, anders krijg je een exception.

Met die methoden wordt het wel compile time gechecked.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

vrijdag 5 januari 2007 16:08

-= Tja =-

Als je al je dao's netjes in een unittest (eigenlijk is het een integratietest) stopt (zoals het hoort) dan hoef je niet eerst te deployen om de geldigheid van je queries te testen.

Alle dao's staan bij mij ook in unittests, en ik test ook de volledige mapping door via jdbc een object in de db te plaatsen, en via hibernate er weer uit te vissen (en na afloop de velden met elkaar te vergelijken). Dit bespaard veel ellende (vooral als er eigenschappen bijkomen).

[ Voor 44% gewijzigd door Alarmnummer op 05-01-2007 16:02 ]

Acties:

zaterdag 6 januari 2007 21:19

Design-by-buzzword fanatic

Alarmnummer schreef op vrijdag 05 januari 2007 @ 16:01:
Als je al je dao's netjes in een unittest (eigenlijk is het een integratietest) stopt (zoals het hoort) dan hoef je niet eerst te deployen om de geldigheid van je queries te testen.

Alle dao's staan bij mij ook in unittests, en ik test ook de volledige mapping door via jdbc een object in de db te plaatsen, en via hibernate er weer uit te vissen (en na afloop de velden met elkaar te vergelijken). Dit bespaard veel ellende (vooral als er eigenschappen bijkomen).

Jup, zeker als je net als op mijn huidige project een niet al te snel build proces hebt, is het zeer fijn om Hibernate dingen in JUnit te testen. Dan is het stukken sneller.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

zondag 7 januari 2007 10:52

Topicstarter

JKVA schreef op vrijdag 05 januari 2007 @ 16:08:
[...]

Jup, zeker als je net als op mijn huidige project een niet al te snel build proces hebt, is het zeer fijn om Hibernate dingen in JUnit te testen. Dan is het stukken sneller.

Ik zie het gebruik van named queries in JPA dan ook gewoon als het inlezen van een resource. Die controlleer je normaliter ook niet via de compiler. Denk aan het inlezen van .properies of .xml (config) bestanden.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

zondag 7 januari 2007 12:16

-= Tja =-

JKVA schreef op vrijdag 05 januari 2007 @ 16:08:
[...]

Jup, zeker als je net als op mijn huidige project een niet al te snel build proces hebt, is het zeer fijn om Hibernate dingen in JUnit te testen. Dan is het stukken sneller.

Dan voer je lokaal je hibernate testen niet uit, maar laat het mooi door de continuous integration server doen (als jullie die gebruiken). Maar niet testen van doa's vind ik geen optie, ik heb al zo vaak een fout gehad in kleine hibernate configuratie zaken die vaak niet direct terug te vinden zijn.

Verder zit ik meestal op projecten die een agile methodiek hanteren, en zonder feedback ben je niet agile

Dus iedere bron van feedback die ik kan vinden (tot een bepaalde grens trouwens) neem ik op in het agile process: continuous feedback (continunous integration is een bron van continuous feedback).

[ Voor 17% gewijzigd door Alarmnummer op 07-01-2007 10:57 ]

Acties:

maandag 8 januari 2007 09:23

Design-by-buzzword fanatic

Alarmnummer schreef op zondag 07 januari 2007 @ 10:52:
[...]

Dan voer je lokaal je hibernate testen niet uit, maar laat het mooi door de continuous integration server doen (als jullie die gebruiken). Maar niet testen van doa's vind ik geen optie, ik heb al zo vaak een fout gehad in kleine hibernate configuratie zaken die vaak niet direct terug te vinden zijn.

Verder zit ik meestal op projecten die een agile methodiek hanteren, en zonder feedback ben je niet agile Dus iedere bron van feedback die ik kan vinden (tot een bepaalde grens trouwens) neem ik op in het agile process: continuous feedback (continunous integration is een bron van continuous feedback).

Lokaal voer ik ze ook uit. Op mijn werk gebruiken we een Maven 2 ontwikkelstraat die we op mijn huidige project met Eclipse geintegreerd hebben. In Eclipse kun je gemakkelijk een test draaien. Dat doen we op een in memory HSQL DB die gegenereerd wordt op basis van wat we in Spring/Hibernate allemaal geconfigureerd hebben. Daarnaast wordt, tijdens het draaien van maven build, de complete test suite gedraaid. Ik sla die stap overigens bijna altijd over, aangezien het vrij lang duurt eer alle tests gedaan zijn.

Daarnaast wordt dezelfde maven build ook op een centrale server gedraaid. Die triggert elk hele uur als er een CVS commit gedaan is.

Maar unit tests in Eclipse vind ik vooral ideaal als je een HQL aan het maken bent. Dan zit je tenminste niet steeds op een lang build proces te wachten om daarna te merken dat je een typefout gemaakt hebt. Dat scheelt een hele hoop tijd.

De term Agile hoor ik wel vaker de laatste tijd, maar ik ken de exacte principes er niet van. Ik ga ervan uit dat EJB3 ook hiervoor een sterke stap voorwaarts is...

Fat Pizza's pizza, they are big and they are cheezy

Acties:

maandag 8 januari 2007 20:27

-= Tja =-

JKVA schreef op zondag 07 januari 2007 @ 12:16:
[...]
Maar unit tests in Eclipse vind ik vooral ideaal als je een HQL aan het maken bent. Dan zit je tenminste niet steeds op een lang build proces te wachten om daarna te merken dat je een typefout gemaakt hebt. Dat scheelt een hele hoop tijd.

*knikt hoofd*

De term Agile hoor ik wel vaker de laatste tijd, maar ik ken de exacte principes er niet van. Ik ga ervan uit dat EJB3 ook hiervoor een sterke stap voorwaarts is...

De agile stroming omvat een groot aantal methodieken: XP, scrum, RUP etc. Het grote idee achter Agile is dat je requirement changes omarmt (tenslotte zijn ze een deel van de realiteit) en daar stel je je ontwikkel proces ook op in.

Verder probeer je bij Agile projecten zo veel mogelijk aansluiting te krijgen op de werkelijkheid dmv feedback (je bent dus steeds de feedback aan het analyseren en het project daarmee bij te sturen). Dit kan feedback zijn over nieuwe ontwerp inzichten, omgeving, performance etc. Agile kent ook geen big upfront design (zegt trouwens niet dat je helemaal geen design fase hebt) omdat je bij een big upfront design de problemen meestal toch nog niet goed genoeg begrijpt om daar een ontwerp mee te maken "frozen ignorance". Agile kent ook geen big bang oplevering (je levert bij iedere iteratie een volledig werkend en deploybaar product op).

Wat mij persoonlijk aanspreekt is de feedback en dat je bij iedere stap die je neemt af moet vragen of dat meerwaarde heeft. Als een bepaalde stap voor een specifiek project geen meerwaarde heeft, kan je het gerust laten vallen.

Acties:

dinsdag 9 januari 2007 08:52

Design-by-buzzword fanatic

In dat geval is EJB 3 daar dus ook een stap voorwaarts voor. De betere testbaarheid en mindere complexiteit nodigen wel uit tot meer iteratief werken.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

dinsdag 9 januari 2007 10:50

-= Tja =-

JKVA schreef op maandag 08 januari 2007 @ 20:27:
In dat geval is EJB 3 daar dus ook een stap voorwaarts voor. De betere testbaarheid en mindere complexiteit nodigen wel uit tot meer iteratief werken.

Alhoewel het niets heeft te maken met de toepassing van Agile methodologie op EJB3 projecten, vind ik de ontwikkeling van EJB eigenlijk helemaal niet agile.

Een paar kenmerken van Agile projecten zijn:
-probeer eerst je eigen meuk uit. Iets dat bij EJB duidelijk mist. EJB3 is gelukkig wel een stuk beter en kan leren van de ellende uit 2, maar toch.

-korte iteraties zodat je sneller feedback kunt verwerken om de volgende stap beter te kunnen nemen. Bij EJB zijn de periodes tussen verschillende versies wel erg lang.

En als ik EJB3 vergelijk met Spring, zie ik eigenlijk weinig toegevoegde waarde maar wel veel minder controle en veel meer beperkingen. Ik wil zeker een keer iets met EJB3 op een project doen, maar Spring heeft bij mij altijd nog de voorkeur.

[ Voor 4% gewijzigd door Alarmnummer op 09-01-2007 08:58 ]

Acties:

dinsdag 9 januari 2007 13:11

Design-by-buzzword fanatic

Alarmnummer schreef op dinsdag 09 januari 2007 @ 08:52:
[...]

Alhoewel het niets heeft te maken met de toepassing van Agile methodologie op EJB3 projecten, vind ik de ontwikkeling van EJB eigenlijk helemaal niet agile.

Een paar kenmerken van Agile projecten zijn:
-probeer eerst je eigen meuk uit. Iets dat bij EJB duidelijk mist. EJB3 is gelukkig wel een stuk beter en kan leren van de ellende uit 2, maar toch.

Maar EJB 3 shizzle kun je gewoon unit testen. Dat is precies wat je wil. Dat het in een container moet draaien om bij JNDI resources te komen, maakt voor de testbaarheid niet veel uit.

-korte iteraties zodat je sneller feedback kunt verwerken om de volgende stap beter te kunnen nemen. Bij EJB zijn de periodes tussen verschillende versies wel erg lang.

Dat lijkt me juist bij EJB 3 gemakkelijker in te perken door de mindere complexiteit, waardoor je sneller ontwikkelt en door de betere testbaarheid waardoor je code beter om kan gaan met veranderingen.

En als ik EJB3 vergelijk met Spring, zie ik eigenlijk weinig toegevoegde waarde maar wel veel minder controle en veel meer beperkingen. Ik wil zeker een keer iets met EJB3 op een project doen, maar Spring heeft bij mij altijd nog de voorkeur.

Dat geloof ik graag, dat JIJ Spring de voorkeur geeft.

Maar ik neem wel aan dat je het als een grote stap voorwaarts beschouwt dat de standaard steeds meer op de Spring methodiek gaat lijken en voor het gevoel van de ontwikkelaar meer lightweight wordt.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

dinsdag 9 januari 2007 13:57

-= Tja =-

JKVA schreef op dinsdag 09 januari 2007 @ 10:50:
[...]

Ik maakt een opmerking over de ontwikkeling van EJB, niet over de ontwikkeling van EJB projecten.

Dat geloof ik graag, dat JIJ Spring de voorkeur geeft. Maar ik neem wel aan dat je het als een grote stap voorwaarts beschouwt dat de standaard steeds meer op de Spring methodiek gaat lijken en voor het gevoel van de ontwikkelaar meer lightweight wordt.

Mwuah.. ik heb weinig op met EJB, en alhoewel het iets beter is dan de vorige versie, komt er ook weer veel te veel ellende in, bv veel te veel annotations En verder heb je nog steeds geen controle over threads.

Het voordeel aan Spring vind ik dat het mij niet op een bepaalde manier laat werken. Ik heb controle, als ik andere AOP meuk wil, doe ik dat, als ik threads op wil starten doe ik dat. Ik accepteer Spring zo lang het mij vrijheid geeft, op het moment dat ik die vrijheid kwijt raak (denk niet dat dat snel zal gebeuren met Spring), ga ik direct naar een alternatief op zoek. Met EJB heb ik nog veel te veel het gevoel (zelfs met de nieuwe meuk) dat ik niet in de drivers seat zit.

Acties:

momania

iPhone 30! Bam!

JKVA schreef op dinsdag 09 januari 2007 @ 10:50:
[...]
Maar ik neem wel aan dat je het als een grote stap voorwaarts beschouwt dat de standaard steeds meer op de Spring methodiek gaat lijken en voor het gevoel van de ontwikkelaar meer lightweight wordt.

Een stap voorwaarts zou ik het niet willen noemen. Meer een paar stappen minder achter de bestaande andere frameworks/opties aan die je als developer hebt, maar het hobbelt er nog steeds achteraan imo

Ik voel me met EJB3 nog steeds te beperkt, net als wat Alarmnummer ook al een beetje aangeeft.
Ik zie EJB3 als iets wat ik met andere frameworks/tools ook al kan doen, op de zelfde makkelijke manier, maar met meer mogenlijkheden en dus vrijheden als developer.

Zoals ik laatst ook al ergens zei vind ik bv die EJB3 Interceptor specs helemaal een lachertje.
In de EJB3 Interceptor specs heb je een annotation waarmee je een interceptor aan een EJB kan hangen. Een annotation!! Nee, dat haalt lekker de overbodige code weg...

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

woensdag 10 januari 2007 07:00

Acties:

woensdag 10 januari 2007 10:02

Design-by-buzzword fanatic

momania schreef op dinsdag 09 januari 2007 @ 13:57:
[...]

Een stap voorwaarts zou ik het niet willen noemen. Meer een paar stappen minder achter de bestaande andere frameworks/opties aan die je als developer hebt, maar het hobbelt er nog steeds achteraan imo

Ik voel me met EJB3 nog steeds te beperkt, net als wat Alarmnummer ook al een beetje aangeeft.
Ik zie EJB3 als iets wat ik met andere frameworks/tools ook al kan doen, op de zelfde makkelijke manier, maar met meer mogenlijkheden en dus vrijheden als developer.

Mwah, wanneer heb je dan voor het laatst zelf een thread aangemaakt? En kun je daar dan niet bijvoorbeeld een ander mechanisme voor gebruiken dat wel door EJB ondersteund wordt? Tenslotte is de grote kracht van EJB ten opzichte van andere frameworks zoals Spring het remoting gedeelte. Ik maak persoonlijk vrijwel nooit threads, ook niet als ik Spring gebruik.

Bovendien, als je EJB je threads laat managen, wil dat ook zeggen dat je code al out of the box redelijk threadsafe is, mits je je aan de regels van EJB houdt natuurlijk.

Zoals ik laatst ook al ergens zei vind ik bv die EJB3 Interceptor specs helemaal een lachertje.
In de EJB3 Interceptor specs heb je een annotation waarmee je een interceptor aan een EJB kan hangen. Een annotation!! Nee, dat haalt lekker de overbodige code weg...

Het hoeft niet per sé via een annotation. In je deployment descriptor kun je ook interceptors definiëren, zoals default interceptors die voor alle EJB's gelden. Het is idd nog een lachertje, maar ik heb de indruk dat je het nu aardig overdrijft. Bovendien is het naar mijn idee nooit slim om bij een eerste versie van een framework (wat EJB 3.0 toch een beetje is) meteen te verdwalen in de features.

Overigens moeten jullie niet gaan denken dat ik helemaal EJB fan ben en tegen Spring ofzo, maar ik heb wel de indruk dat EJB nog steeds gezien wordt als bloated troep waar niet mee te werken is omdat het dat ooit eens was. Momenteel vind ik Spring ook nog beter, maar ik hoop wel dat de Java EE standaard een beetje inloopt, anders verliest het zijn bestaansrecht en dat zou jammer zijn.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

momania

iPhone 30! Bam!

JKVA schreef op woensdag 10 januari 2007 @ 07:00:
[...]

Mwah, wanneer heb je dan voor het laatst zelf een thread aangemaakt? En kun je daar dan niet bijvoorbeeld een ander mechanisme voor gebruiken dat wel door EJB ondersteund wordt? Tenslotte is de grote kracht van EJB ten opzichte van andere frameworks zoals Spring het remoting gedeelte. Ik maak persoonlijk vrijwel nooit threads, ook niet als ik Spring gebruik.

Bovendien, als je EJB je threads laat managen, wil dat ook zeggen dat je code al out of the box redelijk threadsafe is, mits je je aan de regels van EJB houdt natuurlijk.

Wie had het over threads

Het hoeft niet per sé via een annotation. In je deployment descriptor kun je ook interceptors definiëren, zoals default interceptors die voor alle EJB's gelden. Het is idd nog een lachertje, maar ik heb de indruk dat je het nu aardig overdrijft. Bovendien is het naar mijn idee nooit slim om bij een eerste versie van een framework (wat EJB 3.0 toch een beetje is) meteen te verdwalen in de features.

I know, was maar even een kleine side-note. Tuurlijk zijn die specs nog niet 'volwassen', maar als je al begint met overbodige/nutteloze zaken erin te maken, vraag ik me al af hoe serieus ik het moet nemen.

Overigens moeten jullie niet gaan denken dat ik helemaal EJB fan ben en tegen Spring ofzo, maar ik heb wel de indruk dat EJB nog steeds gezien wordt als bloated troep waar niet mee te werken is omdat het dat ooit eens was. Momenteel vind ik Spring ook nog beter, maar ik hoop wel dat de Java EE standaard een beetje inloopt, anders verliest het zijn bestaansrecht en dat zou jammer zijn.

Er is vast wel mee te werken, alleen ik denk dat weinig mensen zin hebben om het uberhaupt te gaan proberen. Omdat het (bijna) niets nieuws bied, behalve dan dat het nu standaard JEE is.

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

woensdag 10 januari 2007 21:57

Acties:

donderdag 11 januari 2007 07:07

Topicstarter

Alarmnummer schreef op dinsdag 09 januari 2007 @ 13:11:
Het voordeel aan Spring vind ik dat het mij niet op een bepaalde manier laat werken. Ik heb controle, als ik andere AOP meuk wil, doe ik dat, als ik threads op wil starten doe ik dat. Ik accepteer Spring zo lang het mij vrijheid geeft,

Hmmm, ik weet het niet hoor. Je weet toch wel dat juist het niet hebben van bepaalde vrijheden je mischien paradoxaal genoeg juist vrijheden kan geven?

Een low-level web taal als PHP bied je heel veel vrijheden. Je kunt lekker het type weglaten in declaraties, en op je web pagina kun er lekker view code met control en business logic mengen; geen mede programmeur (scripter) die er raar van zal kijken.

Door PHP scripters wordt Java dan ook als benauwend gezien. Java dwingt je namelijk om types te declareren, en de Java scene, alsmede het nieuwe JSF, dwingt je min of meer om in je views alleen view gerelateerde code te zetten.

Ik weet niet of je die vrijheden van PHP nou al te zeer moet waarderen. Het zet de deur wagenwijd open voor legioenen prutsers. Leuk die vrijheid om alles door elkaar te mixen als een berg spaghetti in 1 php pagina. Maar het ontneemd mij de vrijheid om snel en makkelijk aanpassingen te doen. Het ontneemd mij de vrijheid om business rules snel aan te passen. Het ontneemd mij de vrijheid om effectief te refactoren. Etc etc etc...

Dus het feit dat EJB3 de developer in bepaalde richtingen dwingt zou net zoals PHP vs Java juist ook weer andere vrijheden kunnen opleveren. Het niet zelf mogen aanmaken van threads, maar container managed services gebruiken klinkt eigenlijk ook wel ok. Hoe vaak heb ik al niet gezien dat een niet al te ervaren persoon een app server plat ligt door allemaal rare threads te spawnen, die race conditions veroorzaken en die app server verhinderen een clean shutdown te doen. Een meer managed systeem klinkt me dus wel als muziek in de oren.

Blijft natuurlijk wel dat het niet allemaal onnodige complexiteit moet gaan opleveren. Inderdaad, als je voor een simpele timer 7 interfaces moet implementeren en 3 XML bestanden moet schrijven of aanpassen (het spookvoorbeeld van EJB2), dan ben je verkeerd bezig ja.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

donderdag 11 januari 2007 07:27

Design-by-buzzword fanatic

flowerp schreef op woensdag 10 januari 2007 @ 21:57:
[...]

Helemaal eens.

Maar aan de andere kant kan ik me ook wel weer vinden in de stelling dat zelfs EJB 3.0 op sommige gebieden onnodig restrictief is. En dat komt volgens mij niet doordat je geen threads mag starten of de JVM stoppen, maar omdat ze nog steeds EJB's als componenten zien die hergebruikt moeten kunnen worden. (over meerdere appservers/projecten/bedrijven/etc)

En volgens mij gaat nooit iemand dat doen. Dat is in het verleden ook al zo gebleken met de oudere versies waar Sun een complete componentenmarkt voorspeld had (a la Visual Basic) die er nooit is gekomen. (Heel gek, aangezien het bij VB over GUI componenten gaat en EJB's over complexe, totaal niet te hergebruiken, bedrijfsprocessen gaat.

)

Maar goed, dergelijke voorspellingen zorgen ervoor dat die componenten uitwisselbaar en pluggable moeten zijn en volgens mij is dat verreweg de grootste restrictie, kort daarop gevolgd door het remoting verhaal.

Van mij mogen ze die componenten gedachte best wel overboord gooien.

Fat Pizza's pizza, they are big and they are cheezy

Acties:

Stephan Oudmaijer

flowerp schreef op zondag 31 december 2006 @ 16:23:
Nog niet zo lang geleden was het altijd het stokpaardje van de Java (EE) community: lekker zeuren op hoe slecht en zwaar EJB was, en hoe lekker licht iets als Spring wel niet was.

Als ik echter naar de huidige stand van zaken kijk, dan lijkt het erop alsof Spring in de laatste release (v2) alleen maar complexer en zwaarder is geworden, terwijl EJB juist een grote afslankingskuur heeft gehad.

Zo zijn in EJB3 bijvoorbeeld de entity beans afgeschaft. Een vergelijkbare functionaliteit (maar dan veel simpelder) kun je nu bereiken met het algemene JPA (Java Persistence Architecture). JPA staat in principe los van EJB; je kunt het net zo goed gebruiken in een servlet of zelfs gewoon in een stand-alone Java SE applicatie.

Blijft over de session en de message-driven beans, die ook wat lichter zouden moeten zijn geworden. Bang gemaakt door alle negativiteit over EJB vroeger, heb ik me er echter nog nooit aan gewaagt. Nu het dus zo'n stuk lichter is geworden (en lichter is per definitie iets goeds, toch?) ben ik er wel nieuwschierig naar.

Ik vraag me af wie hier dan EJB3 gebruikt (en dan doel ik niet op JPA) en ook kan beamen dat het simpel / leuk / handig is.

Persoonlijk vind ik EJB3 een grote stap voorwaards, jammer alleen dat ik ze nog niet heb kunnen inzetten op een "echt" project omdat ik nog geen Java5 / JEE5 applicatie server heb gehad in projecten om m`n applicaties naar te kunnen deployen.

Als je EJB3 + JSF leuk vindt dan vind je JBoss Seam zeker weten leuk. Ondanks dat iedereen JBoss altijd loopt de bashen is het wel een van de interessantere projectjes van JBoss in mijn ogen.

donderdag 11 januari 2007 10:47

Acties:

donderdag 11 januari 2007 22:53

-= Tja =-

flowerp schreef op woensdag 10 januari 2007 @ 21:57:
Hmmm, ik weet het niet hoor. Je weet toch wel dat juist het niet hebben van bepaalde vrijheden je mischien paradoxaal genoeg juist vrijheden kan geven?

Hmm tja. Persoonlijk heb ik liever de vrijheid om dingen te doen zoals ik ze graag wil doen. Spring bied standaard constructies aan waarmee je in 99% van de tijd goed uit de voeten kan, maar als je iets anders wilt doen, niemand let je.

Dus het feit dat EJB3 de developer in bepaalde richtingen dwingt zou net zoals PHP vs Java juist ook weer andere vrijheden kunnen opleveren. Het niet zelf mogen aanmaken van threads, maar container managed services gebruiken klinkt eigenlijk ook wel ok.

Het probleem is dat je vaak erg gekunstelde oplossingen krijgt om simpele dingen te doen. En dat is een van mijn problemen met EJB: moeilijker doen dan strikt noodzakelijk is.

Bij Spring worden de resources gezet doordat je door een transactionele wrapper duikt. Dus je kunt iedere thread een transactie laten uitvoeren.

Hoe vaak heb ik al niet gezien dat een niet al te ervaren persoon een app server plat ligt door allemaal rare threads te spawnen, die race conditions veroorzaken en die app server verhinderen een clean shutdown te doen. Een meer managed systeem klinkt me dus wel als muziek in de oren.

Het moelijker maken van oplossingen toepassen leid niet tot betere systemen. Ik heb al zo veel EJB meuk gezien waarbij je vooral om de problemen van EJB heen moet worstelen, dan dat je echt inhoudelijk bezig bent.

Enterprise systemen zijn complex. Een omgeving maken waarin developers minder keuzes kunnen maken is voor bepaalde type developers wellicht een betere oplossing. Kijk naar veel grotere bedrijven ( met vaak minder begaafde developers) waar ze developers zo veel mogelijk door een bepaalde straight jacket willen persen. Dat is daar misschien de manier om de kwaliteit in ieder geval overal hetzelfde te houden. En ik denk dat EJB voor dit soort bedrijven een goeie oplossing is.

ps:
Als je al die complexiteit nodig bent, denk ik trouwens dat het Java platform sowieso niet de meest handige keuze is. RoR is voor dat soort projecten denk ik een veel beter alternatief.

[ Voor 5% gewijzigd door Alarmnummer op 11-01-2007 10:54 ]

Acties:

vrijdag 12 januari 2007 07:11

Topicstarter

Alarmnummer schreef op donderdag 11 januari 2007 @ 10:47:
Bij Spring worden de resources gezet doordat je door een transactionele wrapper duikt. Dus je kunt iedere thread een transactie laten uitvoeren.

Dat kan in standaard Java EE toch ook m.b.v. JTA? (bean managed transactions heet dat in EJB termen geloof ik). Bied Spring niet 'gewoon' een JTA wrapper aan?

Het moelijker maken van oplossingen toepassen leid niet tot betere systemen.

Het moet natuurlijk niet echt nodeloos moeilijk worden, maar te makkelijk is raar genoeg ook weer niet goed. In een wat complexere taal als C++ kun je natuurlijk net zo goed prutsen, maar toch zie je gemiddeld veel minder prutsers in C++ dan in PHP of Visual basic. De moeilijkheids graad van de taal fungeert toch als een soort eerste shifting.

Als makkelijkere systemen echt zou leiden tot betere software, waarom is de beste software op onze planneet dan niet automatisch in PHP en dergelijke geschreven?

Hiermee wil ik overigens niet impliceren dat Spring te makkelijk is en daardoor slecht zou zijn. Er zijn zeer grote enterprise systemen (bv ook in het bankwezen) die bijna volledig op Spring bouwen. Maar zoals ik al in de OP al stelde, als ik de docs van Spring doorlees dan vind het ik het eigenlijk helemaal niet zo simpel, iniedergeval dus niet on first sight.

Ik heb al zo veel EJB meuk gezien waarbij je vooral om de problemen van EJB heen moet worstelen, dan dat je echt inhoudelijk bezig bent.

Als je al die complexiteit nodig bent, denk ik trouwens dat het Java platform sowieso niet de meest handige keuze is. RoR is voor dat soort projecten denk ik een veel beter alternatief.

Wat ik van RoR begreep is dat je er welliswaar zeer snel iets standaards mee kunt neerzetten, maar als je wat anders wilt dat het dan al snel heel moeilijk wordt of niet kan. Van de drivers seat lijkt dan mischien niet echt sprake te zijn (de naam impliceert dat al een beetje, net zoals een shooter on rails zoals Panzer Dragoon of Nights into Dreams).

maar omdat ze nog steeds EJB's als componenten zien die hergebruikt moeten kunnen worden. (over meerdere appservers/projecten/bedrijven/etc)

Inderdaad ja, er zouden complete kant en klare libraries moeten komen vol met herbruikbare componenten. Je zou dan aparte componenten gewoon komen kopen en meteen gebruiken, een beetje zoals ActiveX op MS Windows. Dit heb ik alleen nooit zien gebeuren.

It's shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult.

Acties:

vrijdag 12 januari 2007 10:23

Design-by-buzzword fanatic

flowerp schreef op donderdag 11 januari 2007 @ 22:53:
[...]

Inderdaad ja, er zouden complete kant en klare libraries moeten komen vol met herbruikbare componenten. Je zou dan aparte componenten gewoon komen kopen en meteen gebruiken, een beetje zoals ActiveX op MS Windows. Dit heb ik alleen nooit zien gebeuren.

Ik denk ook niet dat het ooit gaat gebeuren, simpelweg omdat de meeste EJB's niet zo generiek inzetbaar zijn dat je ze uberhaupt nodig hebt. EJB's praten (in mijn ervaring tenminste) met resources zoals databases, dus je bent van die structuur afhankelijk. Daarnaast hebben ze bepaalde return types die afgestemd zijn op waarvoor ze gebruikt worden, waardoor de bean in een andere context misschien niet of minder nuttig is.

Ik denk dat de gemiddelde EJB voor dermate specifieke doelen ontwikkeld worden dat hergebruik weinig toegevoegde waarde heeft.

Bovendien denk ik dat weinig bedrijven hun EJB's waar ze veel tijd en geld in gestoken hebben, zomaar openbaar maken zodat de concurrent er ook lekker mee aan de haal kan.

Fat Pizza's pizza, they are big and they are cheezy

Acties: