Friday, 29 June 2018

How to update a spring xml in war without rebuild

Spring Framework overview

Spring makes it easy to create Java enterprise applications. It provides everything you need to embrace the Java language in an enterprise environment, with support for Groovy and Kotlin as alternative languages on the JVM, and with the flexibility to create many kinds of architectures depending on an application’s needs.

Scenario

Suppose your software uses the spring framework via xml files and a spring xml file is contained in a jar inside the war package in lib folder but this file must be fixed.
It's possible update the file xml without a new build because this file during build stage is not compiled (as all xml files) but just moved into jar.
As first step, we need extract the war package to extract the jar using the command below:
 jar -xvf my-web-app-1.0.war
Now in our file system we have the war package and Its contents.
To simplify I suggest you move the jar to another folder.
Suppose the spring xml inside the jar in META-INF folder. So we reproduce (into path location of jar target) the same folder structure and use the following command:
 jar -uf my-jar-1.0.jar META-INF/my-spring-conf.xml
Now the jar contains the xml file updated.
The last step is the update of war package. Similarly to jar update, into path location of war target, we create a folder with lib name and put the jar updated and use the following command:
 jar -uvf my-web-app-1.0.war lib/my-jar-1.0.jar
Now the war package contains the spring xml with the update ant it is ready for the deploy into the application server.

Tuesday, 6 March 2018

How to freeing space from svn repository

With the passage of time, considerably increases the disk space used by svn repository. While the cost of storage has dropped incredibly in the past few years, disk usage is still a valid concern for administrators seeking to version large amounts of data so the maintenance activities about to free disk space becomes necessary. Some of them are:
  • Removing dead transactions;
  • Purging unused Berkeley DB logfiles;
  • Packing FSFS filesystems;
  • Purging the svn history.

Removing dead transactions

Though they are uncommon, there are circumstances in which a Subversion commit process might fail, leaving behind in the repository the remnants of the revision-to-be that wasn't an uncommitted transaction and all the file and directory changes associated with it.
You can use the svnadmin lstxns command to list the names of the currently outstanding transactions and remove them with "svnadmin rmtxns" command.
Example: 
$ svnadmin lstxns myrepos
27
4c3
w33
$ svnadmin rmtxns myrepos `svnadmin lstxns myrepos`

Purging unused Berkeley DB logfiles

Removing unused Berkeley DB logfiles allows you to free disk space. Use the svnadmin list-unused-dblogs command to list the unused logfiles and remove them.
Example:
$ svnadmin list-unused-dblogs /var/svn/repos
/var/svn/repos/log.0000000127
/var/svn/repos/log.0000000128
/var/svn/repos/log.0000000129
$ rm `svnadmin list-unused-dblogs /var/svn/repos`

Prune the history

Also you can prune your history. For example: say you have 180 revisions, you can keep the latest history, say 30 revisions. This may also reduce the size of your subversion repository.
$ svnadmin dump /path/to/current/repo -r150:180 > newsvn.dump
# you can delete the old repo and then
$ svnadmin create /path/to/new/repo
$ svnadmin load /path/to/new/repo < newsvn.dump

Packing FSFS filesystems

FSFS-backed Subversion repositories create, by default, a new on-disk file for each revision added to the repository. Having thousands of these files present on your Subversion server, even when housed in separate shared directories, can lead to inefficiencies. To solve this problem, you can use "svnadmin pack" command. By concatenating all the files of a completed shard into a single “pack” file and  then removing the original per-revision files, svnadmin pack reduces the file count within a given shard down to just a single file. In doing so, it aids filesystem caches and reduces (to one) the number of times a file storage overhead penalty is paid.
Example:
$ svnadmin pack /var/svn/repos
Packing shard 0...done.
Packing shard 1...done.
…
Packing shard 100...done. 
A relevant consideration is that the svnadmin pack command has no effect on BDB-backed Subversion repositories.

Friday, 15 December 2017

How to create war package from command line

It is possible to create, modify and extract a war package from command line using the following commands.
First step, create a new war package with:
1
jar -cvf mywebapp.war myproject
Now you can modify the war already created with:
1
jar -uvf mywebapp.war myproject
Instead to extract the files from war:

1
jar -xvf mywebapp.war

Tuesday, 12 December 2017

Maven - Manage properties at build time using maven filter resource files

Sometimes you may need to use properties to contain a value that can only be supplied at build time. Maven provides a valid mechanism to handle this type of property. Indeed it is possible to put a reference to the property that will contain the value into your resource file using the syntax ${<property name>}. The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml (in $HOME/.m2), a property defined in an external properties file, or a system property.

Suppose we have this pom.xml in our project:
<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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>it.blogspot.informaticaamodomio</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0-SNAPSHOT</version>
  
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project> 
Add the following configuration in your pom.xml to enable the filtering:
<build>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
</build>
To reference a property defined in your pom.xml, the property name uses the names of the XML elements that define the value, with "pom" being allowed as an alias for the project (root) element. Some properties are:
  • ${project.name} refers to the name of the project;
  • ${project.version} refers to the version of the project;
  • ${project.build.finalName} refers to the final name of the file created when the built project is packaged;
  • ${project.groupId} refers to group id of the project;
  • ${parent.version} refers to the version of the parent pom.
At this point we can proceed with an example: let's add some properties to the application.properties file (in the src/main/resources directory, according pom configuration) whose values will be supplied when the resource is filtered:
application.name=${project.name}-${project.version}
application.package.name=${project.build.finalName}
you can execute the following command:
$ mvn process-resources
and the application.properties file under target/classes (and will eventually go into the jar) looks like this:
application.name=myapp-1.0
application.package.name=my-app
Now if you want add an external filter file in your pom.xml you must change the pom configuration:
<build>
    <filters>
      <filter>src/main/filters/filter.properties</filter>
    </filters>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
</build>
So create the filter.properties file and for example add a property:
devMode=true
Now you can use the value of "devMode" into application.properties:
application.name=${project.name}-${project.version}
application.package.name=${project.build.finalName}
application.devMode=${devMode}
As an alternative to the external file (filter.properties) you can create the properties into pom.xml into <properties> xml tag. 
<properties>     <devMode>true</devMode> </properties>
Finally you can also get values from system properties for example, java version, java home, user home. And if all this is not enough, you can define the properties via the command line using the standard Java -D parameter. 
To continue the example, let's change our application.properties file to look like this:
application.name=${project.name}-${project.version}
application.package.name=${project.build.finalName}
java.version=${java.version}
server.ip=${server.ip}
you can execute the following command:
$ mvn process-resources "-Dserver.ip=localhost"

Internal Links

Tuesday, 5 December 2017

Maven - Introduction to build and reporting plugins

Maven is a plug-in execution framework, the plug-ins are classifiers in two types:
  • Build plugins will be executed during the build and then, they should be configured in the <build/> element.
  • Reporting plugins will be executed during the site generation and they should be configured in the <reporting/> element.

Build plugins

An example of build plugin is:
    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <configuration>
                <myString>a string</myString>
                <myBoolean>true</myBoolean>
                <myInteger>10</myInteger>
            </configuration>
          </plugin>
        </plugins>
      </build>
      ...
    </project> 
The example below uses the <executions> element, this element is used when the plug-in participates in some phases of the build lifecycle:
    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <executions>
              <execution>
                <id>execution1</id>
                <phase>test</phase>
                <configuration>
                  <myString>a string</myString>
                  <myBoolean>true</myBoolean>
                  <myInteger>10</myInteger>
                </configuration>
                <goals>
                  <goal>mygoal</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
      ...
    </project>
The id "execution1" binds this configuration to the test phase.
You could configure the dependencies of the Build plugins with <dependencies> element:
    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <executions>
              <execution>
                <id>execution1</id>
                <phase>test</phase>
                <configuration>
                  <myString>a string</myString>
                  <myBoolean>true</myBoolean>
                  <myInteger>10</myInteger>
                </configuration>
                <goals>
                  <goal>mygoal</goal>
                </goals>
              </execution>
            </executions>
            <dependencies>
              <dependency>
                <groupId>it.blogspot.informaticaamodomio</groupId>
                <artifactId>my-app</artifactId>
                <version>1.0</version>
              </dependency>
            </dependencies>
          </plugin>
        </plugins>
      </build>
      ...
    </project>
By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could uses the <inherited> element:
    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <inherited>false</inherited>
            .......
          </plugin>
        </plugins>
      </build>
      ...
    </project>

Reporting plugins

As first statement, configuring a reporting plugin in the <reporting> or <build> elements in the pom does not have the same behavior.
For example the "mvn site" uses only the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element, site always ignores the parameters defined in the <configuration> element of each plugin specified in <build>. So I suggest adding it only in <reporting> element.
You can configure a reporting plugin using the <reportSets> tag. This is most commonly used to generate reports selectively when running mvn site. Example:
<project>
...
  <reporting>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-project-info-reports-plugin</artifactId>
        <version>${plugin.version}</version>
        <reportSets>
          <reportSet>
            <reports>
              <report>project-team</report>
            </reports>
          </reportSet>
        </reportSets>
      </plugin>
    </plugins>
  </reporting>
...
</project>
If you want exclude all reports, use the following reportSets configuration:
<reportSets>
    <reportSet>
        <reports/>
    </reportSet>
</reportSets>
As build plugins (for more information see [1]), you can use <inherited> element.
<inherited>false</inherited>

Internal Links

Monday, 4 December 2017

Maven - Introduction to the dependency management

The "Transitive dependencies" feature allows you to avoid needing to discover and specify the libraries that your own dependencies require, and including them automatically.
The "dependency scope" is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks. There are 6 scopes available:
  • "compile" is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project.
  • "provided" is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime.
  • "runtime" indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
  • "test" indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive.
  • "system" is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
  • "import" is only supported on a dependency of type pom in the <dependencyManagement> section. It indicates the dependency to be replaced with the effective list of dependencies in the specified POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
The "Dependency Management" section is a mechanism for centralizing dependency information. It can be used when two POMs extend the same parent. Example:
Pom of Project A
   <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-app</artifactId>
          <version>1.0</version>
          <exclusions>
            <exclusion>
              <groupId>it.blogspot.informaticaamodomio</groupId>
              <artifactId>my-artifact</artifactId>
            </exclusion>
          </exclusions>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <type>jar</type>
          <scope>test</scope>
        </dependency>
      </dependencies>
    </project>
Pom of Project B
   <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-artifact-b</artifactId>
          <version>1.0</version>
          <type>war</type>
          <scope>runtime</scope>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <type>jar</type>
          <scope>test</scope>
        </dependency>
      </dependencies>
    </project>
Now we can apply the dependency management adding the dependencyManagement section in Pom Parent (the order of dependencies is not relevant):
   <project>
      ...
      <dependencyManagement>
        <dependencies>
          <dependency>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>my-artifact-b</artifactId>
            <version>1.0</version>
            <type>war</type>
            <scope>runtime</scope>
          </dependency>
          <dependency>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>my-app</artifactId>
            <version>1.0</version>
            <exclusions>
              <exclusion>
                <groupId>it.blogspot.informaticaamodomio</groupId>
                <artifactId>my-artifact</artifactId>
              </exclusion>
            </exclusions>
          </dependency>
          <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <type>jar</type>
            <scope>test</scope>
          </dependency>
        </dependencies>
      </dependencyManagement>
    </project>
Now update the dependencies section in both Poms.
Pom of Project A
   <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-artifact-b</artifactId>
          <!-- This is not a jar dependency, so we must specify type. -->
          <type>war</type>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
        </dependency>
      </dependencies>
    </project>
Pom of Project B
    <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-artifact-b</artifactId>
          <!-- This is not a jar dependency, so we must specify type. -->
          <type>war</type>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
        </dependency>
      </dependencies>
    </project>

Internal Links

Friday, 1 December 2017

Introduction to Maven Pom structure

Taking the example of a simple pom shown in [1] we analyze in detail its content:
  • project tag is the top-level element in all pom.xml files.
  • modelVersion tag indicates what version of the object model this pom is using.
  • groupId tag indicates the unique identifier of the organization or group that created the project.
  • artifactId tag indicates the unique base name of the primary artifact being generated by this project.
  • packaging tag indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). If this tag is not present so the default value is jar.
  • version tag indicates the version of the artifact generated by the project.
  • name tag indicates the display name used for the project.
  • url tag indicates where the project's site can be found.
  • description tag provides a basic description of your project.
Name, url and description tags are often used in Maven's generated documentation.
Instead the dependencies tag contains the dependency list, in our example there is just junit dependency. A dependency is structured as:
 <dependency>
        <groupId>${mydependency.groupId}</groupId>
        <artifactId>${mydependency.artifactId}</artifactId>
        <version>${mydependency.version}</version>
        <scope>${mydependency.scope}</scope>
        <type>${mydependecy.type}</type> 
 </dependency>
Scope and type are optional, (if it is not present) the default value for scope is "compile". The default value for type is "jar". More details will provided in future posts.

Internal Links

Welcome

Hello everybody, Welcome in my blog called "Information technology archive". Obviously the topics will be related to Informatio...