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!):
- 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 - 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
- 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. - 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.
