Sahoo wrote:
> Tim,
>
> The pom changes look fine. I am assuming you did not find any other
> way of addressing the issue but to duplicate.
Unfortunately, no.
The dtds and schemas modules are distribution-fragments. The resulting
zip files do not survive the installation; instead their contents are
expanded into the ${installRoot}/lib directory. If they were delivered
as module JARs instead then the appclient/client/acc module could simply
depend on them directly, without any further processing required. (The
server's SaxParserHandler - as does the ACC's - could then use
getResource to locate a .dtd or .xsd entry along the classpath rather
than using directory navigation and file access.)
> Can you tell how user can upgrade the embedded schemas when she
> downloads a newer version of schemas placed in lib/schemas/ directory
> via update centre?
The same way as other modules that depend on the schema and DTD list.
The specific names and information about .dtd and .xsd files are coded
into various DOL classes. In the scenario you describe, the module(s)
containing such classes would already need to be delivered as part of
the same update that delivers the new schemas themselves. The updated
gf-client-module.jar which contains copies of the DTDs and schemas would
need to be included in such an update bundle, but it would require just
the same handling during the update process as the other JARs.
Later, when an end-user launches an app client after the update has been
applied, Java Web Start and our logic in GlassFish detect that the
client's cached copies of the affected JARs are out-of-date, and the
newer versions are downloaded from the server's directory to the client.
- Tim
>
> Thanks,
> Sahoo
> Tim Quinn wrote:
>> Hi.
>>
>> These pom changes are simple in concept but verbose in expression in
>> the pom!
>>
>> Basically, during a Java Web Start launch of an app client we need to
>> have the .xsd and .dtd files packaged into a JAR that is in the class
>> path at runtime. This way the entity resolver can use getResource to
>> locate the .xsd or .dtd content rather than disk files because the
>> files to not exist in extracted directories during a Java Web Start
>> launch.
>>
>> So, these pom changes are basically in two parts;
>>
>> 1. Use the dependency plug-in to extract the .dtd files from the
>> deployment/dtds module, and the .xsd files from the
>> deployment/schemas module, into this module's target/dependency
>> directory.
>>
>> 2. Define the directories which will contains these extracted files
>> as part of the resource set so the build will automatically bundle
>> them into the module JAR.
>>
>> (I also took the opportunity to clean up a couple of stray lines and
>> inaccurate comments. There is no point to creating an index on this
>> JAR because we don't launch this JAR directory during app client
>> runs, which is the only time an index is useful.)
>>
>> Many thanks.
>>
>> - Tim
>>
>>
>>
>> Index: appclient/client/acc/pom.xml
>> ===================================================================
>> --- ../../../appclient/client/acc/pom.xml (revision 29028)
>> +++ ../../../appclient/client/acc/pom.xml (working copy)
>> @@ -100,10 +100,53 @@
>> <include>**/*.properties</include>
>> </includes>
>> </resource>
>> +
>> + <!--
>> + The next resource definitions will include the DTDs and
>> + schemas in the module so we can find them at runtime
>> in the
>> + client. The dependency:unpack-dependency goal below
>> will
>> + by default deposit the unpacked contents into
>> + target/dependency. The .dtd and .xsd files are
>> packaged into
>> + their respective JARs in glassfish/lib, so we define
>> that
>> + combined directory as a resource
>> + location so the .dtd and .xsd files will be packaged
>> by default.
>> + This is coordinated with the SaxParserHandlerBundled
>> class
>> + which resolves entities via the class path.
>> + -->
>> + <resource>
>> + <directory>target/dependency/glassfish/lib/</directory>
>> + <includes>
>> + <include>**/*.dtd</include>
>> + <include>**/*.xsd</include>
>> + </includes>
>> + </resource>
>> </resources>
>>
>> <plugins>
>> +
>> + <!--
>> + Unpack the modules which contain the DTDs and
>> schemas so
>> + we can package them as resources.
>> + -->
>> <plugin>
>> + <groupId>org.apache.maven.plugins</groupId>
>> + <artifactId>maven-dependency-plugin</artifactId>
>> + <executions>
>> + <execution>
>> + <id>unpack-dtds-and-schemas</id>
>> + <phase>generate-resources</phase>
>> + <goals>
>> + <goal>unpack-dependencies</goal>
>> + </goals>
>> + <configuration>
>> +
>> <includeGroupIds>org.glassfish.deployment</includeGroupIds>
>> +
>> <includeArtifactIds>schemas,dtds</includeArtifactIds>
>> + <includes>**/*.dtd,**/*.xsd</includes>
>> + </configuration>
>> + </execution>
>> + </executions>
>> + </plugin>
>> + <plugin>
>>
>> <!--
>> <groupId>org.apache.maven.plugins</groupId>
>> @@ -138,8 +181,6 @@
>>
>> <archive>
>>
>> - <index>true</index>
>> -
>> <manifest>
>>
>> <mainClass>org.glassfish.appclient.client.acc.AppClientCommand</mainClass>
>>
>> <!--
>> @@ -222,10 +263,8 @@
>> <!--
>> We depend on the deployment/dtds module which contains the
>> sun-application-client-container_1_2.dtd. We use that for
>> - generating JAXB classes but we do not want to package
>> the DTD
>> - with the ACC module, nor do we want the ACC module
>> depending on
>> - the deploymenet/dtds module at runtime. Note the scope
>> is "compile"
>> - to indicate this.
>> + generating JAXB classes. We depend on both the DTDs and
>> + the schemas at runtime.
>> -->
>> <dependency>
>> <scope>compile</scope>
>> @@ -235,6 +274,14 @@
>> <version>${project.version}</version>
>> </dependency>
>>
>> + <dependency>
>> + <scope>runtime</scope>
>> + <groupId>org.glassfish.deployment</groupId>
>> + <artifactId>schemas</artifactId>
>> + <type>zip</type>
>> + <version>${project.version}</version>
>> + </dependency>
>> +
>> <!--
>> <dependency>
>> <groupId>javax.xml.bind</groupId>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>