Skillnader mellan J2EE 1.3 och 1.4

J2SE 1.3 -> J2SE 1.4

J2EE 1.3 -> J2EE 1.4

Nya API:er

• Web services ingår (Web Services for J2EE, JAXR (även ett register), JAX-RPC och SAAJ)
• J2EE Management API, J2EE Deployment API och JMX för administration (används främst av verktyg).
• J2EE Authorization Service Provider Contract for Containers (JACC) ger ett SPI för security providers.

Övriga utökningar

• Klassbibliotek kan deployas oberoende av applikation och kan då användas av alla instalerade applikationer.
• Lokala EJB:er kan accessas från en web container.

Ändringar

• DD specificerad med schema i stället för DTD.

Servlet 2.3 -> 2.4

Ändringar

• DD specificerad med schema i stället för DTD.
• Pathen i getRequestDispatcher() måste anges relativt aktuell servlet.
• SingleThreadModel är deprecated.
• Klasser somär gemensamma för olika webapplikationer måste laddas av samma ClassLoader för alla webapplikationer i samma JVM. Denna ClassLoader måste vara en av förfäderna till webapplikationens ClassLoader.
  

Utökningar

• Welcome files kan vara servlets.
• Servern måste klara både HTTP 1.0 och HTTP 1.1.
• Servern får ha en cache enligt RFC2616 vilket bland annat innebär att servern får svara på ett request utan att anropa den servlet det är riktat till.

EJB 2.0 -> 2.1

Ändringar

• DD specificerad med schema i stället för DTD.

Utökningar

• Tillståndslösa sessionsbönor kan vara web services.
• Alla ejb:er får anropa externa web services.
• Det finns en timer. Alla ejb:er utom stateful sessions beans kan ta emot hädelser från en timer.
  
• Andra meddelandestandarder än JMS får användas av message-driven beans.
• Sortering och ett flertal funktioner tillagde till EJB QL.

JSP 1.2 -> 2.0

Ändringar

• Använd inte isThreadSafe i direktivet page eftersom SingleThreadModel är deprecated.
• Det är inte längre tillåtet att använda klasser i det anonyma paketet i en JSP.
  

Utökningar

• Expresson Language, EL
  Ett enkelt scriptspråk som kan användas överallt i template text och i attribut som tillåter request time-evaluering. EL ser ut så här:
• Inga deklarationer eller tilldelningar är möjliga.
• Det finns ingen flödeskontroll förutom operatorn ?:
• Namnrymden utgörs av attribut i PageContext (alla scope) och implicita objekt (inte samma som i script i Java).
• Operatorn [] ger access till properties i en böna och till medlemmar i en Map, List eller primitiv array.
• Det finns logiska, aritmetiska och jämförelseoperatorer.
• Statiska, publika metoder specificerade i en TLD kan anropas från EL.

EL syftar framför allt till att eliminera expressions. Eftersom JSTL kan eliminera scriptlets som används för flödeskontroll och deklarationer (av funktioner) nu kan placeras i taglib borde Java-kod i JSP:er oftast helt kunna undvikas utan att egna taggar behöver skrivas. EL borde också minska behovet av bönor eftersom det går att definiera metoder i TL. Detta innebär att det inte behövs bönor för "utility-metoder" (i stil med getDate()).


• Det finns nu en DD för JSP
  Den är definierad med ett schema som importeras av DD i servlet-specen och är alltså en del av web.xml. I DD för JSP kan detta anges:
• tag libraries
• Om EL och /eller script i Java ska tillåtas.
• JSP-fragment som ska inkluderas först eller sist i en JSP-sida.
• Om en JSP är definierad som ett XML-dokument.
  
  
• Nya standard actions:
• <jsp:element>
  Används för att dynamiskt (vid request time) ange namnet på en action.
  
• <jsp:attribute>
  Används för att ange ett attribut till en action (vilken som helst). Värdet av detta attribut ges då i bodyn till <jsp:attribute>. Vinsten är att attributets värde kan anges i en body. Denna action behövs också för att ange ett attribut i en action som är angedd med <jsp:element> (se ovan).
  
• <jsp:body>
  Om <jsp:attribute> används för att specificera attributen till en action måste dess body anges med <jsp:body>.
• <jsp:output>
  Styr (tillsammans med <jsp:root>) XML-prologen (<?xml version="1.0" encoding=... ?> osv) som genereras av ett JSP-dokument. Denna action får alltså bara användas i JSP-dokument, inte i JSP-sidor.
  
• <jsp:invoke> och <jsp:doBody>
  Dessa används i tag files (se nedan).
  
  
• JSP Documents
  Detta avsnitt är förtydligat och utökat och verkar mer användbart nu. Till exempel kan både taggar som tolkas (JSP actions osv) och sådana som skickas till klienten definieras i XML (om utdatat är tex XHTML, SOAP eller SVG). Detta kan då även definieras i en DTD och valideras (tex av containern). Vidare kanske JSP-dokumentet lättare kan genereras med XSLT eller skrivas i någon XML-editor. Går det kanske att skapa  JSP-dokumentet automatiskt med till exempel JAXB?
  
  Några exempel på nyheter:
  
  • Det är tydligare definierat hur JSP-dokument processas, tex anges att XML-entiteter tolkas och att XML quoting används i stället för JSP quoiting.
  • Förhållandet mellan JSP-sidor, JSP-dokument och XML view är tydligare definierat. Se figur JSP.6-1 på sid 1-133 i specen.
  • I JSP-dokument identifieras både custom och standard actions mha XML namespaces.
  • Det är definierat hur JSP-dokument valideras av containern: Finns en DOCTYPE angiven måste DTD-validering ske. Andra typer av validering, som tex schema, är inte tillåtet.
  • XML-vyn av ett JSP-dokument är något utökad, tex definieras alltid contentType och pageEncoding och vyn innehåller ett <jsp:root>-element.
  • XML-vyn av en JSP-sida är ganska oförändrad. Notera (fast detta är lika i 1.2 och 2.0) att när en JSP-sida omvandlas till en XML-vy placeras allt template data i bodyn till en <jsp:text>. När ett JSP-dokument omvandlas, däremot, placeras template data i form av XML-taggar inte i en <jsp:text>. Det innebär att i det senare fallet kan även utdatat till klienten valideras.
  EXEMPEL PÅ JSP-DOKUMENT (OCH VALIDERING?) ANVÄND DE NYA STANDARD ACTIONS OVAN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  
  
• Tag Extensions (taglibs)
  Det API som fanns i JSP 1.2 (Tag, IterationTag, BodyTag) finns kvar oförändrat. Dessutom finns ett nytt API, kallat Simple Tag Handlers. Dessa kan bara användas om inga script (dvs Java-kod) finna i taggens body. Detta API definieras av det enda interfacet SimpleTag och skiljer sig från det äldre API:et huvudsakligen enligt nedan:
• Java-klasserna som implementerar taggen cachas aldrig. Klasserna måste ha en konstruktor utan argument som används för att skapa en ny instans varje gång taggen ska exekveras.
• Klasserna som implementerar taggen får aldrig kännedom om PageContext, utan använder i stället en ny klass, JSPContext. Den senare är en superklass till PageContext och innehåller allt som tidigare fanns i den senare och inte har något beroende av servlets (tex ServletRequest och ServletResponse).
• Om en simple tag har en body placeras bodyn i en JSPFragment som skickas till taggimplementationen innan den exekveras. Detta fragment kan exekveras (precis som om det stod i en JSP-sida) genom att metoden invoke() anropas.
• Simple tags har inte den komplexa livscykeln och därför inte heller alla de metoder det äldre API:et innehöll. I stället finns en enda metod, doTag(), som ska innehålla allt processande av taggen. En kortfattad beskrivning av simple tags livscykel finns i javadocen för javax.servlet.jsp.tagext.SimpleTag.
Det är svårt att se någon anledning att använda det äldre API:et (eller script).

Övriga nyheter vad gäller taglibs är:

• Det går att lägga till attribut som inte var definierade när taggen skapades utan att tagimplementationen ändras. Om så ska kunna ske ska klassen som implementerar taggen implementera interfacet DynamicAttributes.
• Ett taglib kan innehålla händelselyssnare (enligt servlet 2.4).


• Tag Files
  En tag file är en simple tag (se ovan) som är definierad i JSP-syntax i stället för Java-syntax. En sådan fil ska ha extension tag eller tagx och fungerar i princip som en vanlig JSP-fil. Undantagen är att en tag file använder direktivet tag i stället för page och att den kan innehålla direktiven attribute och variable, vilka mostvarar samma element i en TLD. Vidare får standard actions <jsp:invoke> och <jsp:doBody> bara finnas i en tag file. De motsvarar ett anrop av metoden invoke() i en simple tag. I det första fallet gäller anropet ett JspFragment som är värdet av ett attribut och i det andra fallet ett JspFragment som är taggens body.
  
  En tag file kan placeras på två olika ställen. Det första är i META-INF/tags eller någon katalog under den i en jar-fil i WEB-INF/lib. Det andra är i WEB-INF/tags eller någon underkatalog till den. I det första fallet måste det finnas en TLD, i det andra fallet skapas TLD:n automatiskt av containern.
  EXEMPEL PÅ TAG FILE!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

JavaServer Pages Standard Tag Library (JSTL) 1.1

Java Authorization Contract for Containers (JACC) 1.0

Containern vet detta:

• java.security.Principal för den tråd/användare som exekveras (via det javax.security.auth.Subject som returnerats av aktuell JAAS LoginModule.
• Vilka rättigheter en viss roll har (via deployment descriptorn).
• Vilken javax.security.jacc.PolicyConfiguration som används (via javax.security.jacc.PolicyConfigurationFactory).
• Vilken java.security.Policy som används (via system proprtyn javax.security.jacc.policy.provider).

JACC-Service providern vet detta:

• Vilka rättigheter en viss roll har (via sin javax.security.jacc.PolicyConfiguration ).
• Aktuell policy context (via javax.security.jacc.PolicyContext.getContextID()).
• Vilken java.security.Principal som exekverar (genom den javax.security.auth.Subject som returneras av anropet javax.security.jacc.PolicyContext.getContext("javax.security.auth.Subject.container");)
• Med hjälp av nycklarna i avsnitt 4.6.1 i specen går det att få ytterligare objekt av javax.security.jacc.PolicyContext som kan ge mer information inför beslutet om den efterfrågade rättigheten ska beviljas.
• Mappning mellan roller och principals (via ett privat API).

Hur går det till att avgöra om en viss rättighet ska ges?