mercredi avr. 28, 2010

WEB-INF/lib/{\*.jar}/META-INF/resources

This blog has moved to alexismp.wordpress.com
Follow the link for the most up-to-date version of this blog entry.

Modularity is one of the themes for Java EE 6 and servlet 3.0 fragments one often mentioned as one examples of this (see details here). This blog entry is about a small yet very useful new feature of the servlet 3.0 specification to deal with static content such as images, CSS or JavaScript.

Before servlet 3.0, images could be made accessible from the root of the web applications but that meant copying the files to the WAR archive and keeping them up-to-date. This certainly meant a solution tightly coupled with the web application development and packaging. The other option was to place this static content in the docroot of the application server which was in turn time probably too loosely coupled allowing for anyone to access this and encouraging every application to use the same set of static content.

With Servlet 3.0, a JAR placed in WEB-INF/lib has static content from its META-INF/resource directory accessible from the web-context root. You can also parse this previous statement with WEB-INF/lib/{\*.jar}/META-INF/resources. So this means you no longer need to use the ServletContext getResource() and getResourceAsStream() methods with some rather dumb rewriting.

In this simple web application WAR example :

... the static resources are available from :

http://host:port/webcontext/scripts.js
http://host:port/webcontext/styles.css
http://host:port/webcontext/welcome.png


where http://host:port/webcontext/ could be replaced with the relative path "./"

This makes for more modular applications. Other than images, think of how this applies to CSS and javascript. It's probably now a good idea to package JavaScript libraries such a jquery or dojo in a dedicated JAR (effectively a resource JAR).

The other use-case I can think of is configuration files. One could deploy with WEB-INF/lib/testing.jar or with WEB-INF/lib/production.jar each of which containing META-INF/resources/config.properties file with different content. The application code reading the configuration would always access it using ./config.properties (or http://host:port/webcontext/config.properties).

Note this mechanism also applies to JSPs and that resource files placed in the document root take precedence. Get all the details from paragraph 10.5 of the Servlet 3.0 specification.

Try this out today in GlassFish 3 and above.

lundi mars 08, 2010

GlassFish without the IDE (quick survival guide)

This blog has moved to alexismp.wordpress.com
Follow the link for the most up-to-date version of this blog entry.

A lot of people experiment GlassFish for the first time via an IDE (most likely NetBeans, but maybe also with Eclipse) and feel a bit lost when it comes to use GlassFish without the tool driving it for them. So here are a few (mostly basic) CLI asadmin hints for GlassFish v3 :

* Start/Stop *
Start GlassFish (need this to access the admin console on default port http://localhost:4848) :
     % GLASSFISH_HOME/bin/asadmin start-domain     (assumes there's only one domain)
     % asadmin start-domain domain1     (explicitly reference a given domain)
     % asadmin start-domain -v domain     (will cause the log to be dumped to the standard output)
     % java -jar modules/glassfish.jar     (may be useful in certain circumstance (explicit java version for instance)

Stop GlassFish :
     % asadmin stop-domain {domain1}

List existing instances (including stopped/started status)
     % asadmin list-domains

You can also create additional domains with % asadmin create-domain ... (and I would suggest using the -portbase option).

* Resources *
If the IDE has created connection pools and datasources, you will certainly find the following create-jdbc-connection-pool and create-jdbc-resource commands useful. Note also that asadmin has a "closest match" feature for misspelled commands and extensive online documentation :
% ~/glassfishv3/bin/asadmin create
CLI001 Invalid Command: create
Closest matching local and remote command(s):
     create-admin-object
     create-audit-module
     create-auth-realm
     create-connector-connection-pool
     create-connector-resource
     create-connector-security-map
     create-connector-work-security-map
     create-custom-resource
     create-domain
     create-file-user
     create-http
     create-http-listener
     create-iiop-listener
     create-javamail-resource
     create-jdbc-connection-pool
     create-jdbc-resource
     create-jms-host
     create-jms-resource
     create-jmsdest
     create-jndi-resource
     create-jvm-options
     create-lifecycle-module
     create-message-security-provider
     create-network-listener
     create-password-alias
     create-profiler
     create-protocol
     create-resource-adapter-config
     create-resource-ref
     create-service
     create-ssl
     create-system-properties
     create-threadpool
     create-transport
     create-virtual-server

Almost every bits of configuration is located in the glassfish/domains/domain1/config/domain.xml config file but you really should be using asadmin or the admin console and not edit this by hand.

Starting with GlassFish 3.1, you can use "application-scoped resources" (see documentation, screencast). Such resources are created at deploy-time, usable only by the application they ship with and are destroyed upon undeploy.

* (auto)deployment *
The explicit deployment is based on the asadmin deploy app.{ear|war|jar} command. Listing deployed applications is as easy as asadmin list-application (notice how GlassFish tells you which containers are at work for a given app), and undeployment simply requires a asadmin undeploy app-name.

While these commands have lots of options (asadmin deploy --help for details), you may find it convenient to simply drop your application in the domain1/autodeploy directory. Deleting the file will trigger the undeployment.

All the details for the asadmin CLI can be found in the official "Using the asadmin Utility" documentation.

* JavaDB/Derby database *
If you'd like to move your tables and data from the JavaDB instance used in NetBeans to another one (maybe the one that ships with GlassFish), exporting the data and creating one from the backup is probably a good approach if you don't have SQL code to re-created it all. Look for "Backing up and restoring databases" in the Derby Admin Guide.

About

This blog has moved

Alexis Moussine-Pouchkine's Weblog

GlassFish - Stay Connected

Search

Archives
« avril 2014
lun.mar.mer.jeu.ven.sam.dim.
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today
Blogroll

No bookmarks in folder

News

No bookmarks in folder