Osadzone molo: jak używać .war, który jest zawarty w .jar, z którego zaczyna Jetty?

Question

Próbuję wygenerować plik .jar zawierający main(), który uruchomi Jetty.

Moim problemem jest to, że chciałbym .war że Jetty ładunki być zawarte w tym samym .jar.

byłem w stanie stworzyć .jar zawierającego .war z:

W pom.xml:

<plugin> 
    <artifactId>maven-assembly-plugin</artifactId> 
    <version>2.3</version> 
    <configuration> 
     <finalName>myApp</finalName> 
     <appendAssemblyId>false</appendAssemblyId> 
     <archive> 
      <manifest> 
       <mainClass>com.myApp.Server</mainClass> 
      </manifest> 
     </archive> 
     <descriptors> 
      <descriptor>src/main/resources/executable-jar-assembly.xml</descriptor> 
     </descriptors> 
    </configuration> 
    <executions> 
     <execution> 
      <id>make-my-jar-with-dependencies</id> 
      <phase>package</phase> 
      <goals> 
       <goal>single</goal> 
      </goals> 
     </execution> 
    </executions> 
</plugin> 

executable-jar-assembly.xml:

<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" 
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd"> 

<id>jar-with-dependencies-and-war</id> 
<formats> 
<format>jar</format> 
</formats> 
<includeBaseDirectory>false</includeBaseDirectory> 
<dependencySets> 
    <dependencySet> 
     <outputDirectory>/</outputDirectory> 
     <useProjectArtifact>false</useProjectArtifact> 
     <unpack>true</unpack> 
     <scope>runtime</scope> 
    </dependencySet> 
</dependencySets> 
<fileSets> 
    <fileSet> 
     <directory>target/classes/</directory> 
     <outputDirectory>/</outputDirectory> 
    </fileSet> 
    <fileSet> 
     <directory>target/</directory> 
     <includes> 
      <include> 
       myApp.war 
      </include> 
     </includes> 
     <outputDirectory>/</outputDirectory> 
    </fileSet> 
</fileSets> 

Kod ustawić wojny w pomost:

handler.setWar("myApp.war"); 

... Próbowałem również:

URL res = Server.class.getResource("myApp.war"); 
handler.setWar(res.toExternalForm()); 

... i:

URL res = Thread.currentThread().getContextClassLoader().getSystemResource("myApp.war"); 
handler.setWar(res.toExternalForm()); 

Ale nic nie działa!

Przy użyciu tego ostatniego przykładowego kodu, aby uruchomić Jetty, serwer wydaje się, aby rozpocząć poprawnie, ale żadne żądania nie działają. Konfiguracja jest oczywiście błędna.

Wiem, że są pewne sposoby obejścia pliku .war, który jest wykonywalny, ale chciałbym, aby ".war" wewnątrz pracy .jar ".

Każdy pomysł na konfigurację .war?

Answer 1

Grałem z tym dużo w sezonie 2009-10 dla konkretnej aplikacji.

Problemem, który znalazłem, jest to, że kiedy masz wojnę osadzoną w słoiku, identyfikatory URI mogą w końcu być takie, które nie działają z domyślnym sterownikiem URI jar: próbującym uzyskać dostęp do pliku wojny.

Istnieje szereg rozwiązań, które znalazłem:

1. Tell pomost wyodrębnić/eksplodować plik war do tymczasowego katalogu

2. zaimplementować własną obsługi URI (to było ciekawe ćwiczenia , ale jeśli potrzebujesz obsługiwać kod samodzielnie, nie polecałbym tego)

3. Spraw, aby plik wojenny był wykonywalnym plikiem wojennym, np. ten sam rodzaj sztuczki używany przez Jenkinsa. Aby to zrobić, nakładasz na siebie klasy serwerów pomostowych i główną klasę z plikiem wojennym. Następnie wskaż przystań do pliku JAR jako pliku wojennego.Jetty nie obchodzi, że nazwa pliku nie kończy się .war

Cała trójka pracowała dla mnie na Jetty 7. Podejrzewam, że sytuacja pozostanie taka sama.

Ostatecznie zdecydowałem się na opcję 3. Działa jako najprostszy, nie pozostawia plików tymczasowych w systemie użytkownika i jest najszybszy do uruchomienia.

Answer 2

Próbowałem jak ty z plikiem wojennym w słoiku, ale pomost zdawał się służyć mi w katalogu z plikiem wojennym jako jedynym wpisem, który uznałem za dziwny ... Nie jestem pewien, czy zrobiłem coś złego tam ...

Odkryłem, że eksplodowanie pliku wojny w katalogu wewnątrz pliku jar wydawało mi się skuteczne. Mogę później odkryć pewne dziwne rzeczy, ale dopóki to zrobię, pozostanę z tym.