Specificare le dipendenze "fornite" con graal sotto Maven
-
28-10-2019 - |
Domanda
Ho un'applicazione grails 1.3.7. Sto utilizzando le classi JMS di Spring per configurare uno dei miei servizi grails come ascoltatore di messaggi, impostando quelle classi in grails-app / conf / resources.groovy. Sto usando Maven 2.0.9 per le build, usando il plugin Grails-Maven-1.3.7 e l'obiettivo "maven-war" per creare un file war.
Ho due scenari:
- Voglio essere in grado di eseguire la mia app grails localmente, dalla riga di comando, utilizzando "mvn grails: run-app". Lo uso durante lo sviluppo.
- Voglio essere in grado di eseguire l'app in JBoss 5.1.0 GA, distribuendo il file war creato da Maven. Questo è ciò che facciamo nei nostri ambienti di integrazione, test e produzione.
Quando si esegue in JBoss, tutte le dipendenze correlate al provider JMS sono disponibili e fornite dal server delle applicazioni. Il modo normale di gestirlo con Maven è dichiarare queste dipendenze nel file pom, con lo scopo di "fornito". Questo renderà queste dipendenze disponibili per la compilazione e gli unit test, ma le escluderà dal file war.
Tuttavia, quando eseguo localmente dalla riga di comando usando "mvn grails: run-app", sembra che queste dipendenze non siano disponibili per grails in fase di esecuzione, come evidenziato da molte eccezioni ClassNotFound, ecc. La modifica dell'ambito in "compile" mi consente di eseguire localmente. Tuttavia, ora queste dipendenze vengono impacchettate nel mio file war, che non voglio e tende a rompere le cose durante l'esecuzione in JBoss.
La soluzione (o soluzione alternativa) che ho trovato per ora è includere queste dipendenze JMS con l'ambito predefinito (compilazione) nel mio pom e rimuovere questi jar (e tutte le loro dipendenze transitive) dal file war tramite del codice in BuildConfig .groovy (vedi sotto). Funziona, ma è disordinato e soggetto a errori perché devo elencare ogni singola dipendenza transitiva (di cui ce ne sono molte!).
Alcune altre cose che ho provato:
All'inizio, ho pensato che forse avrei potuto aggiungere le dipendenze JMS richieste a BuildConfig.groovy, nella sezione "grails.project.dependency.resolution / dependencies", e lasciarle completamente fuori dal pom. Tuttavia, questo non ha funzionato perché, secondo questo link , la sezione delle dipendenze BuildConfig viene ignorata quando si esegue grails sotto Maven.
Ho anche notato l'opzione "pom true" (menzionata nel link sopra) e ho provato a usarla. Tuttavia, quando si tenta di eseguire grails: run-app, grails genera avvisi sulle dipendenze non risolte e fornisce un errore tomcat:
:::: WARNINGS
::::::::::::::::::::::::::::::::::::::::::::::
:: UNRESOLVED DEPENDENCIES ::
::::::::::::::::::::::::::::::::::::::::::::::
:: commons-collections#commons-collections;3.2.1: configuration not found in commons-collections#commons-collections;3.2.1: 'master'. It was required from org.grails.internal#load-manager-grails;1.2-SNAPSHOT compile
:: org.slf4j#slf4j-api;1.5.8: configuration not found in org.slf4j#slf4j-api;1.5.8: 'master'. It was required from org.grails.internal#load-manager-grails;1.2-SNAPSHOT runtime
...
java.lang.LinkageError: loader constraint violation: when resolving overridden method "org.apache.tomcat.util.digester.Digester.setDocumentLocator(Lorg/xml/sax/Locator;)V" the class loader (instance of org/codehaus/groovy/grails/cli/support/GrailsRootLoader) of the current class, org/apache/tomcat/util/digester/Digester, and its superclass loader (instance of <bootloader>), have different Class objects for the type org/xml/sax/Locator used in the signature
at org.grails.tomcat.TomcatServer.start(TomcatServer.groovy:212)
La mia domanda: Esiste un modo migliore, tramite Grail e / o opzioni di configurazione Maven, per ottenere ciò che voglio, ovvero essere in grado di eseguire graal con successo localmente e all'interno di JBoss, senza dover escludere manualmente tutte le dipendenze transitive dal file war?
Nota: non posso cambiare la versione di Grails, JBoss o Maven che sto usando.
Alcuni estratti di file rilevanti:
BuildConfig.groovy:
grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
grails.project.war.file = "target/${appName}-${appVersion}.war"
grails.project.dependency.resolution = {
// inherit Grails' default dependencies
inherits("global") {
// uncomment to disable ehcache
// excludes 'ehcache'
}
log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose'
repositories {
// only use our internal Archiva instance
mavenRepo "http://my-company.com/archiva/repository/mirror"
mavenLocal()
}
dependencies {
// specify dependencies here under either 'build', 'compile', 'runtime', 'test' or 'provided' scopes eg.
}
//Remove own log4j and use the one supplied by JBoss instead
grails.war.resources = {stagingDir ->
delete file:"$stagingDir/WEB-INF/classes/log4j.properties" // logging conf done in JBoss only
def files = fileScanner {
fileset(dir:"$stagingDir/WEB-INF/lib"){
[
// all of the following are jms-related dependencies supplied by JBoss
/* org.jboss.javaee */ "jboss-jms-api-*.jar",
/* org.jboss.naming */ "jnp-client-*.jar",
/* org.jboss */ "jboss-common-core-*.jar",
/* org.jboss.logging */ "jboss-logging-spi-*.jar",
/* jboss.messaging */ "jboss-messaging-*.jar",
/* org.jboss.aop */ "jboss-aop-*.jar",
/* org.apache.ant */ "ant-*.jar",
/* org.apache.ant */ "ant-launcher-*.jar",
/* org.jboss */ "jboss-reflect-*.jar",
/* org.jboss */ "jboss-mdr-*.jar",
/* qdox */ "qdox-*.jar",
/* trove */ "trove-*.jar",
/* org.jboss.logging */ "jboss-logging-log4j-*.jar",
/* org.jboss.remoting */ "jboss-remoting-*.jar",
/* jboss */ "jboss-serialization-*.jar",
/* oswego-concurrent */ "concurrent-*.jar",
/* org.jboss.jbossas */ "jboss-as-cluster-*-jboss-ha-legacy-client.jar",
/* commons-logging */ "commons-logging-*.jar",
/* org.jboss.jbossas */ "jboss-as-server-*.jar",
/* sun-jaxb */ "jaxb-api-*.jar",
/* org.jboss.jbossas */ "jboss-as-deployment-*.jar",
/* org.jboss.javaee */ "jboss-jad-api-*.jar",
/* org.jboss.security */ "jboss-security-spi-*.jar",
. . . // and the other 74 transitive dependencies...
].each{
include(name:it)
}
}
}
files.each
{
delete(file: it)
}
}
}
pom.xml:
<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
. . .
<dependencies>
. . .
<dependency>
<!-- already a dep of grails-crud; make it scope:compile for resources.groovy -->
<groupId>org.springframework</groupId>
<artifactId>spring-jms</artifactId>
<version>3.0.5.RELEASE</version>
</dependency>
<!-- Note: all the remaining jms dependencies below should be 'provided' scope, but
grails doesn't correctly pull them in when running locally, so we must leave
them as compile scope and remove them (and their transitive dependencies) from
the war file through BuildConfig.groovy
-->
<dependency>
<groupId>org.jboss.javaee</groupId>
<artifactId>jboss-jms-api</artifactId>
<version>1.1.0.GA</version>
</dependency>
<dependency>
<groupId>org.jboss.naming</groupId>
<artifactId>jnp-client</artifactId>
<version>5.0.3.GA</version>
</dependency>
<dependency>
<groupId>jboss.messaging</groupId>
<artifactId>jboss-messaging</artifactId>
<version>1.4.3.GA</version>
</dependency>
<dependency>
<groupId>org.jboss.aop</groupId>
<artifactId>jboss-aop</artifactId>
<version>2.1.1.GA</version>
<classifier>client</classifier>
<exclusions>
<exclusion>
<!-- see http://jira.codehaus.org/browse/GROOVY-3356 -->
<groupId>apache-xerces</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.jboss.remoting</groupId>
<artifactId>jboss-remoting</artifactId>
<version>2.5.3.SP1</version>
</dependency>
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-serialization</artifactId>
<version>1.0.3.GA</version>
</dependency>
<dependency>
<groupId>oswego-concurrent</groupId>
<artifactId>concurrent</artifactId>
<version>1.3.4-jboss-update1</version>
</dependency>
<!-- the following two are required in order to connect to HA-JNDI -->
<dependency>
<groupId>org.jboss.jbossas</groupId>
<artifactId>jboss-as-cluster</artifactId>
<classifier>jboss-ha-legacy-client</classifier>
<version>5.1.0.GA</version>
</dependency>
<dependency>
<groupId>org.jboss.cluster</groupId>
<artifactId>jboss-ha-client</artifactId>
<version>1.1.1.GA</version>
</dependency>
<!-- End dependencies for connecting to JMS -->
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.grails</groupId>
<artifactId>grails-maven-plugin</artifactId>
<version>1.3.7</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>init</goal>
<goal>maven-clean</goal>
<goal>validate</goal>
<goal>config-directories</goal>
<goal>maven-compile</goal>
<goal>maven-test</goal>
<goal>maven-war</goal>
<goal>maven-functional-test</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
resources.groovy:
import org.codehaus.groovy.grails.commons.ConfigurationHolder
import org.springframework.jms.connection.UserCredentialsConnectionFactoryAdapter
import org.springframework.jms.listener.DefaultMessageListenerContainer
import org.springframework.jms.listener.adapter.MessageListenerAdapter
import org.springframework.jms.support.destination.JndiDestinationResolver
import org.springframework.jndi.JndiObjectFactoryBean
import org.springframework.jndi.JndiTemplate
beans = {
def config = ConfigurationHolder.config
jndiTemplate(JndiTemplate) {
environment = config.myQueue.ctx.toProperties() // flattens a{b{c}} to 'a.b.c'
}
jmsFactory(JndiObjectFactoryBean) {
jndiTemplate = jndiTemplate
jndiName = config.myQueue.connectionFactory as String
lookupOnStartup = false // need this?
proxyInterface = "javax.jms.ConnectionFactory"
}
authJmsFactory(UserCredentialsConnectionFactoryAdapter) {
targetConnectionFactory = jmsFactory
username = config.app.auth.username as String
password = config.app.auth.password as String
}
destinationResolver(JndiDestinationResolver) {
jndiTemplate = jndiTemplate
}
jmsMessageListener(MessageListenerAdapter, ref("myMessageDrivenService")) {
defaultListenerMethod = "onEventMessage"
}
jmsContainer(DefaultMessageListenerContainer) {
connectionFactory = authJmsFactory
destinationResolver = destinationResolver
destinationName = config.eventQueue.queueName as String
messageListener = jmsMessageListener
transactionManager = ref("transactionManager") // grails' txn mgr
cacheLevel = DefaultMessageListenerContainer.CACHE_CONNECTION
autoStartup = false // started up in Bootstrap.groovy
}
}
Soluzione
La soluzione per questo è creare un ambito dinamico per la tua dipendenza tramite un profilo.
Esempio:
<?xml version="1.0" encoding="utf-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
. . .
<properties>
<jms.deps.scope>compile</jms.deps.scope>
</properties>
<profile>
<id>build</id>
<properties>
<jms.deps.scope>provided</jms.deps.scope>
</properties>
</profile>
<dependencies>
<dependency>
<groupId>whatever</groupId>
<artifactId>whatever</artifactId>
<scope>${jms.deps.scope}</scope>
</dependency>
</dependencies>
. . .
Quindi, quando la riga di comando specificherà il profilo:
mvn clean install war -P build
Spero che questo aiuti.
Altri suggerimenti
Questo problema è stato "risolto" in Grails 2.0.Il plug-in maven per grails è stato aggiornato in modo che l'ambito "fornito" significhi che la dipendenza è disponibile quando viene eseguita localmente, ma non è inclusa nel file war del pacchetto.