SGES2 a nové JAX-WS a JPA2

Pěkně to tu mají napsané, pěkně. A vždycky to má háček. No, našel jsem trochu jinou cestičku. Java si vždycky hledá takové properties soubory, ve kterých má napsanou default implemetaci nějakého API.
Ale asi bych měl začít od začátku - problém byl takový: Naučili jsme SGES2.1.1 novým kouskům tak, že jsme v adresáři lib udělali pár změn (AS, ne domény!):

1. Souborům toplink-essentials-agent.jar, webservices-rt.jar, webservices-tools.jar, endorsed/activation.jar a endorsed/webservices-api.jar jsme přihodili příponu .Orig - to aby je aplikáč nenačítal, ale abychom měli nějakou stopu po tom, že jsme tu prováděli "psí kusy".
   Ještě malá poznámka - toplink-essentials.jar nepřejmenováváme, jelikož ho potřebuje interní ejb timer a nám konec konců nevadí, protože JPA providera si vybírá každá aplikace dle svého gusta v persistence.xml.
   

   cd ${appserv.home}
   mv ./lib/toplink-essentials-agent.jar ./lib/toplink-essentials-agent.jar.Orig
   mv ./lib/webservices-rt.jar ./lib/webservices-rt.jar.Orig
   mv ./lib/webservices-tools.jar ./lib/webservices-tools.jar.Orig
   mv ./lib/endorsed/activation.jar ./lib/endorsed/activation.jar.Orig
   mv ./lib/endorsed/webservices-api.jar ./lib/endorsed/webservices-api.jar.Orig
   

2. Do adresáře lib nakopírujeme nové soubory. K dostání jsou obvykle na stránkách autorů nebo v různých maven repositories. Co přesně musíte stáhnout se může lišit podle toho, jak moc se vzdálíte od staré implementace, ale každopádně bude třeba pokrýt to, co plnily přejmenované knihovny. Náš seznam je následující - Javě je jedno, jak se soubory jmenují, podstatné je, že mají příponu .jar, tudíž jsme ponechali i čísla verzí:
   

   webservices-rt-2.2.jar
   webservices-tools-2.2.jar
   eclipselink-2.3.2.jar
   endorsed/javax.persistence-2.0.3.jar
   endorsed/webservices-api-2.2.jar

3. To jsem napsal v podstatě totéž, co mají na odkazu v začátku. Jenže při prvním nasazení aplikace zjistíte, že pokud v persistence.xml vyplníte element <class>, aplikace vám neprojde validací!!!
   Háček je totiž v tom, že AS se řídí různými properties, poházenými po classpath v knihovnách v adresáři META-INF/services. Ty mu říkají "default" implementace API, které on sám použije; název souboru je v našem případě javax.persistence.spi.PersistenceProvider.properties
   Protože jsme ale nechali na classpath TopLink, má AS na výběr mezi TopLinkem a EclipseLinkem. Který zvolí, záleží na tom, který soubor najde dřív - čili nejspíš TopLink, protože při startu pravděpodobně bude nahazovat EjbTimer.
4. Slova "pravděpodobně" a "nejspíš" se mi nelíbí, ale řešení je snadné - do aplikace si ten property soubor přidejte taky :-)
   A potom zapomeňte na pokusy dávat knihovny na classpath-prefix, což navrhují v onom odkazu - zkoušel jsem to, nefunguje to.

A ještě troška deziluze - zapomeňte na to, že vám SGES2 kdy bude dělat JEE6 server. Takovou certifikací neprošel a nikdy neprojde, prostě taková funkcionalita kontejneru v něm není. Nikdy nebude umět pracovat s anotacemi podle JEE6, prostě protože se musí pevně držet JEE5.
JEE5 Aplikace sice bude bezpečně fungovat na JEE6 serveru, ale to pořád neznamená, že vnitřně JEE6 server obsahuje JEE5 server. Toto nejsou Windows!
Důvody zpětné kompatibility jsou jen anotace a API - vaše JEE5 aplikace jimi deklaruje nějaké požadavky (na zdroje, transakce, atd.), ale vůbec tím neříká, jak je server má splnit (pokud ovšem nepoužívá "deprecated" atributy anotací nebo něco neloví přes InitialContext).
Zkrátka, pokud chcete JEE6, musíte přejít na nějaký certifikovaný  JEE6 aplikáč. Třeba Glassfish3, ať nechodíte daleko.

Tenhle návod vedl jen k tomu, abychom mohli použít např. Criteria API, nové JAX-WS a pár dalších novinek.

EDIT: Jeden příklad toho, co nebude fungovat - SGES používá tuto implementaci EntityManager wrapperu - ano, tušíte správně, metodu z JPA2 díky němu nevyvoláte, čili například nemůžete použít TypedQuery.