Problem ze sposobem kompilacji albo serwerm Glassfish'a

Witam,

mam problem z naszym środowiskiem JAVA. Posiadamy dwie wersje: LIVE oraz DEV.

Wersja LIVE siedzi sobie na serwerze i działa. Niestety wersja DEV po użyciu akcji "Republish" nie działą prawidłowo i w logach Glassfish'a pod odpowiednią domeną mam to:

[#|2012-01-03T15:36:30.637+0000|WARNING|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=26;_ThreadName=Thread-1;|StandardWrapperValve[servlet]: PWC1382: Allocate exception for servlet servlet
java.lang.UnsupportedClassVersionError: WEB9032: Class com.storeq.gwt.server.ServiceImpl has unsupported major or minor version numbers, which are greater than those found in the Java Runtime Environment version 1.6.0_26
	at org.glassfish.web.loader.WebappClassLoader.findClass(WebappClassLoader.java:943)
	at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1430)
	at org.apache.catalina.core.StandardWrapper.loadServletClass(StandardWrapper.java:1383)
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1247)
	at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:1059)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:187)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
	at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
	at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
	at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:322)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
	at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
	at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
	at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
	at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
	at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
	at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
	at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
	at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
	at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
	at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
	at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
	at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
	at java.lang.Thread.run(Thread.java:662)
|#]

Bardzo proszę was o pomoc bo ten problem uniemożliwia nam wystawienie wersji developerskiej i rozwala cały tryb pracy.

Dla mnie to wygląda jakbyś miał w tym środowisku DEV niezaktualizowaną wersję Runtime javy. Spróbuj zaktualizować wersję runtime do tej którą masz w ide

Serwer DEV śmiga na Javie 6, w IDE i na LIVE masz 7.

angel2953 napisał(a)

Dla mnie to wygląda jakbyś miał w tym środowisku DEV niezaktualizowaną wersję Runtime javy. Spróbuj zaktualizować wersję runtime do tej którą masz w ide

Czyli programista, który kompiluje plik .war musi u siebie podczas kompilacji mieć dokładnie taką samą wersję co runtime na serwerze Glassfish'a ?

Boję się, że po uaktualnieniu czegoś na serwerze przestanie działać i stara wersja LIVE i nowa DEV (bo znowu coś wyskoczy)

Koziołek napisał(a)

Serwer DEV śmiga na Javie 6, w IDE i na LIVE masz 7.

Tylko że te środowiska działają na jednym serwerze. Raz "Redepoly" jest pliku xxx.war a innym razem xxxdev.war i potem jest to wybierane w zależności od tego czy ktoś wpisze xxx.com/xxx/ czy xxx.com/xxxdev/.

Planet Soft napisał(a)

Czyli programista, który kompiluje plik .war musi u siebie podczas kompilacji mieć dokładnie taką samą wersję co runtime na serwerze Glassfish'a ?

Patrz: http://koziolekweb.pl/2011/10/07/o-kompatybilnosci-wstecznej-javac-slow-kilka/ javac ma opcję -target, ale nie gwarantuje ona, że kod zostanie uruchomiony.

Planet Soft napisał(a)

Raz "Redepoly" jest pliku xxx.war a innym razem xxxdev.war i potem jest to wybierane w zależności od tego czy ktoś wpisze xxx.com/xxx/ czy xxx.com/xxxdev/

Niech zgadnę dev.war kompilujecie lokalnie na stanowisku losowego łosia-programisty? IMO warto zainwestować trochę czasu i postawić serwer CI> Ciągła integracja wtedy takie problemy z znacznym stopniu znikną.

Przy kompilacji korzystam z jre1.6.0_26 war'a tworzę za pomocą jar.exe z jdk1.6.0_26 i nadal jest ten sam błąd w logach Glassfish'a

A weź zobacz co javap produkuje dla klasy com.storeq.gwt.server.ServiceImpl. Bo może tam siedzi jakiś babol. BTW, to jest biblioteka, czy wasz kod?

Jest to nasz kod, polecenie javap w CMD na maszynie z Windowsem na której jest kompilowany kod jest nieznane. Co mam doinstalować aby to zadziałało ?

javap w standardowym JDK. Jak nie bangla to podaj pełną ścieżkę. Katalog ten sam co dla javac.

C:\Program Files\Java\jdk1.6.0_26\bin>javac com.storeq.gwt.Server.ServiceImpl
error: Class names, 'com.storeq.gwt.Server.ServiceImpl', are only accepted if an
notation processing is explicitly requested
1 error

C:\Program Files\Java\jdk1.6.0_26\bin>javap com.storeq.gwt.Server.ServiceImpl
ERROR:Could not find com.storeq.gwt.Server.ServiceImpl

Ok, problem został rozwiązany zmianą wersji Java SDK na serwerze na 1.7.0.2 - najnowsza skompilowana wersja działa więc to nam wystarczy. Dziękuję za całą otrzymaną pomoc.