L'esperienza del server JavaEE è importante per uno sviluppatore?

Questo è il punto in cui sento che la visione aziendale di Sun per Java non è riuscita. L'idea è che i server delle applicazioni variano solo in base all'implementazione e qualsiasi app Java può essere rilasciata in qualsiasi contenitore e "funziona".

Se leggevi la loro letteratura sin dai primi giorni, hanno anche chiamato ruoli specifici, come sviluppatori che hanno appena scritto bean, assemblatori che hanno appena preso i bean e li hanno assemblati in jar di ejb e definiscono i descrittori di deployment e, naturalmente, gli amministratori di sistema chi gestisce il server delle applicazioni stesso, che come precedentemente affermato, è completamente disaccoppiato dalle app al suo interno.

In realtà, non funziona mai così. Ci deve sempre essere qualcosa di diverso nell'app per distribuirlo in un altro contenitore.

Esempi:

• Pool di connessioni al database - ogni server di app è diverso. Alcune app web lo fanno persino da sole.
• Caching - In particolare, JBoss ha classi all'interno dei suoi pacchetti che facilitano le invalidazioni della cache a livello di cluster. Non puoi più rilasciare il tuo codice in Jetty.
• Test - se ops vuole aggiornare Tomcat, cosa deve essere testato? È sicuro? Solo l'ingegneria può dirlo e il controllo qualità può verificare.
• Gestione della configurazione - poiché la configurazione del contenitore non fa parte delle specifiche Java EE, i file di configurazione sono sempre specifici del container. È molto comune per i programmi di installazione delle applicazioni configurare il contenitore per te, controllando i file di configurazione nel controllo del codice sorgente o scrivendo script per aggiornare i file di configurazione del contenitore.
• Percorsi di classe - dove vanno a finire tutti i tuoi JAR? So che dicono di mettere tutto nelle classi WEB-INF / lib e WEB-INF /. Hah. Che dire del driver JDBC? Oh si, va sotto $ TOMCAT_HOME / lib. Oppure $ JBOSS_HOME / server / servername / deploy / lib o qualcosa del genere. Quindi aggiorni JBoss e ora è $ JBOSS_HOME / standalone / lib. Non aspettarti che le operazioni di aggiornamento lo facciano senza dev. E non farmi iniziare sui problemi del classpath di log4j.
• I contenitori hanno spesso metodi predefiniti per risolvere i problemi, ma sacrifichi la portabilità. Ad esempio, vedo spesso la compressione HTTP gestita a livello di contenitore o server Web Se, come sviluppatore, vuoi abilitarlo, configureresti un filtro servlet all'interno della tua app web o "flip the switch" sul tuo contenitore e / o web server?

Il mio elenco potrebbe continuare all'infinito.

I find it stupid and ridiculous to ask for some one with a specific server implementation experience.

Sulla base della mia esperienza limitata, il nostro team di sviluppo è anche responsabile del container J2EE. Ci assicuriamo che il codice e il server risolvano insieme il problema su cui stiamo lavorando. Chi altri potrebbe avere una tale visione di quali strumenti o strutture sono necessari per il corretto funzionamento del codice? Il sysadmin è quindi responsabile della macchina stessa e per rendere il contenitore J2EE piacevole con tutto il resto (firewall, ecc.).

What kinds of features exist amongst Java application containers that require such specialized skill?

Penso che si tratti di quadri qui. Una base di codice costruita su Struts e Hibernate non deve preoccuparsi, in realtà, su quale contenitore è in esecuzione.

Alla fine, l'esperienza in uno specifico contenitore J2EE non ha importanza se l'applicazione o le strutture su cui è basata gestiscono le differenze per te. Tuttavia, anche se questo è vero, l'esperienza con quel contenitore potrebbe ancora essere vista come un vantaggio.

(3+ anni di sviluppo su JBoss)