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.

samedi janv. 16, 2010

Testing with the GlassFish Maven plugin and JavaDB Embedded

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

Having GlassFish v3 usable in embedded mode made it easy to create a maven plugin with multiple goals (see this previous entry). This in turn makes it easy to configure the plugin for maven-driven unit testing. Here's an example :

<plugin>
    <groupId>org.glassfish</groupId>
    <artifactId>maven-embedded-glassfish-plugin</artifactId>
    <version>3.0</version>
    <configuration>
       <goalPrefix>embedded-glassfish</goalPrefix>
       <app>${basedir}/target/myapp.ear</app>
       <autoDelete>true</autoDelete>
       <port>8080</port>

    </configuration>

    <executions>
       <execution>
          <id>start-glassfish</id>
          <phase>pre-integration-test</phase>
          <goals>
             <goal>start</goal>
          </goals>
       </execution>
       <execution>
          <id>glassfish-deploy</id>
          <phase>pre-integration-test</phase>
          <goals>
             <goal>deploy</goal>
          </goals>
       </execution>
       <execution>
          <id>glassfish-undeploy</id>
          <phase>post-integration-test</phase>
          <goals>
             <goal>undeploy</goal>
          </goals>
       </execution>
       <execution>
          <id>stop-glassfish</id>
          <phase>post-integration-test</phase>
          <goals>
             <goal>stop</goal>
          </goals>
       </execution>
    </executions>
</plugin>

Now it's certainly nice to be able to automate tests right from a single pom.xml and not have to deal with starting, deploying, stopping the app server. It's even better when the runtime starts fast and uses only the required memory (as it is the case with GlassFish v3), but what about running tests involving a database? If a database server needs to be started using external tools (or worse, manually) it's a bit back to square "one".

This is where JavaDB embedded can come in handy. The trick with an application server like GlassFish is that it's not enough to use the embedded driver (org.apache.derby.jdbc.EmbeddedDriver), you also need to reference an embedded JTA datasource. GlassFish v3 ships with one such datasource pre-configured: jdbc/__TimerPool so lazy as I am, I simply reused this in by setup - using the following JPA persistence-unit enables my test to fire up an embedded (in-process) instance of JavaDB (no separate startup, no port used). As the names implies, this pool isn't really a general purpose one (it's used for by the Timer Service) so this is a bit of a hack. A handy one, but a hack.

<persistence-unit name="tempdb">
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <jta-data-source>jdbc/__TimerPool</jta-data-source>
    <properties>
       <property name="javax.persistence.jdbc.driver" value="org.apache.derby.jdbc.EmbeddedDriver"/>
       <property name="eclipselink.target-database" value="DERBY"/>
       <property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
    </properties>
</persistence-unit>

You see here that I use the drop-and-create-tables ddl generation strategy (create-tables would work too) and consider the database to be volatile. The next step would be to run all of this in-memory and no longer write files to disk (which shouldn't be that hard).

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