Handling VAADIN WebApp MANIFEST

General
1

Hi !

I’m trying to read the MANIFEST File inside a WebApp in order to get some informations as application build number or versions.

I’ve tried to use this piece of code to handle this :

InputStream inputStream = getContext().getClass().getResourceAsStream("/META-INF/MANIFEST.MF");
Manifest manifest = new Manifest(inputStream);
			Attributes atrs = manifest.getMainAttributes();
 for (Iterator it=atrs.keySet().iterator(); it.hasNext(); ) {
		            // Get attribute name
		            Attributes.Name attrName = (Attributes.Name)it.next();
		    
		            // Get attribute value
		            System.out.println(attrName+":"+atrs.getValue(attrName));
		        }

this code is executed inside a VAADIN Application class.

But it seems the only thing I can get from this is an other manifest.
The output result is

instead of that

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: Administrateur
Build-Jdk: 1.6.0_11
Hudson-Build-Number: 388
Hudson-Project: testProject
Hudson-Version: 1.332
Implementation-Version: r-3307
Specification-Version: 0.0.1-SNAPSHOT

Has anyone experienced this probleme ?

cheers

2

If you need Vaadin framework version, it can be read from
http://vaadin.com/api/com/vaadin/terminal/gwt/server/AbstractApplicationServlet.html#VERSION
.

3

Actually, I mean my own version of a jar packaged in my Vaadin web application.

I wrote a manifest inside it which is automaticily built when packaing my jar.

I have to access the manifest inside this jar and get some properties I put into its manifest (like build number…)

But in order to display it in a vaadin application, I need to access it from the webapp via the servlet context.

4

The webapp context will give you access to the WebApp Manifest

ApplicationContext ctx = getContext(); final ServletContext sCtx = ((WebApplicationContext)ctx).getHttpSession().getServletContext(); will give you access to the WebApp context, from which you can retrieve the manifest with the getResourceAsStream routine.

The webapp manifest is the one you should be updating with a version number, and you should be getting it with code as above.

If you search the web, you will find discussions on how the “getResourceAsStream” method differs – there is a version on the Class class, and a version on the ServletContext class, and they don’t quite do the same thing.

5

thx for your quick response.

I tried this but it seems that Vaadin isn’t using a standart Servlet contexte or maybe I’m wrong

Here is the error message I get

java.lang.ClassCastException: com.vaadin.terminal.gwt.server.ApplicationServlet cannot be cast to javax.servlet.Servlet
	at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1104)
	at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:806)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:129)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:619)

Any ideas ?

6

Vaadin is using com.vaadin.terminal.gwt.server.WebApplicationContext, which the example referred to.
Note that this is not the same as e.g. WebAppContext of jetty.

This looks like a classloader issue: javax.servlet.Servlet has been loaded with a different classloader than ApplicationServlet (or by two different classloaders), and the JVM does not consider them to be compatible with each other. It is unclear, though, why this occurs here.

Solving this might require some server-specific classpath management.

7

Thx for ur response.

Indeed there might be a classpath problem not relatated with my previous problem stated int this post.
I try to fix it and come back for feedbacks.

[EDITS]

The conflict came from the dependency I just added

		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>servlet-api</artifactId>
			<version>2.5</version>
		</dependency>

which I needed to get the context as stated by Jean-François Lamy

If i’v well understood this problem, the classloader loads the wrong servlet class and that’s why this error happens.

8

These classes and interfaces are already provided by the runtime environment (servlet container).

If you don’t otherwise have these on your classpath (from GWT, Jetty, or some other library) when compiling, it might help to tell Maven only to use this dependency at compilation time but not deploy your copy of it for runtime:

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.5</version>
            <scope>provided</scope>
        </dependency>
9

It definitely works !

I’m happy that this forum can both help us on vaadin and furthermore give some advices when using it with Maven :wink:

Thx a lot for all ur contributions to this post, it was a nice teamplay :slight_smile: