Embracing Glassfish and OSGi - A Developer's Note

Glassfish OSGi-JavaEE Part4 : The ways of deploying an OSGi Application into Glassfish

In the Part3, we have seen how to create a web application bundle(WAB) and deploy it into Glassfish.

Since I have mentioned "deployment",  in this part, I will make a priority description for how to deploy an OSGi Application into Glassfish.

Why? Maybe you can ask me why not continuing to look into WAB or EJB bundle's implementation mechanism  in depth?

The reason is as following:

1)  all inside info about Glassfish OSGi-JavaEE start from deployment, or saying, deployment is the next parts's bootstrap point.

2) Glassfish OSGi-JavaEE Application deploying process is a glue between Glassfish JavaEE containers and pure OSGi context, without the glue, we can not continue our story.

So, I will introdue Glassfish OSGi-JavaEE's deployment in this Part and Part5. In this Part, I will introduce the ways of deploying an OSGi Application into Glassfish; And in the Part5, I will bring you an looking into the backend of deploying an OSGi Application in depth.

As far as I know, there are three ways of deploying an OSGi Application into Glassfish.

1. using "asadmin deploy --type=osgi"

eg. for a WAB(assuming we call it  "helloworldwab")  which has been built, we can use the following command to deploy it,

>asadmin deploy --type=osgi  /.../.../helloworldwab-1.0-SNAPSHOT.war

If deploying successfully, you will see the following similar image.

Noting: we must add "--type=osgi" option, otherwise, you am deploying a common war rather than wab. I have seen many such errors in glassfish jira.

The command will cause the following results:

1)  the wab is expanded into default domain's applications directory

Just as common JavaEE deployment, the wab is also expanded into glassfish default domain's applications directory, eg. in my enviroment, a helloworldwab-1.0-SNAPSHOT directory is generated under domain1/applications

Noting: the above deployment command has not specified --target, so defaultly, this will deploy the wab in default domain's server instance.

2) the wab related configuration info is written into default domain's domain.xml

Apart from generating a helloworldwab-1.0-SNAPSHOT directory, the wab related configuration info is also written into default domain's domain.xml.  Eg. in my enviroment, the added wab info is as following:

The behavior  means that the wab has been in the management context of glassfish admin infrustructure. Eg. the management context can do the following for the wab later,

- while the whole system is in cluster mode, the WAB will enjoy the capabilities which glassfish cluster brings. (About the point, I need to confirm deeply and once having any result, I will write a seperate part for it)

3) default domain's osgi-cache will generate the wab's bundle revision info

You can see the generated wab's bundle revision info by entering glassfish4\glassfish\domains\domain1\osgi-cache\felix\

There is more quick and easy way to see current deployed bundles info in current Glassfish v4. You can execute the following command:

>asadmin osgi lb

The above result displayed that our helloworldwab has been installed and started successfully, and it has a bundle id called "293", state is "Active". 

You may be curious why bundle id is 293  rather than 290?

OK, this is because after you deployed a bundle(id=290) then undeployed the bundle, if you deployed the bundle again, then, the bundle id will be 291, so I must do several times back and force, :)

By the way, "asadmin osgi lb" can list many installed bundles info, so if you know some bundles's keyword and want to find these bundles's bundle id quickly, you can use the following:

>asadmin osgi lb | grep HK2 (linux/unix)

or

>asadmin osgi lb | findstr HK2 (windows)

2. dropping the wab into "autodeploy\bundles\" directory

This is also called autodeploying mode. This is very convenient and Sahoo has an outstanding article about the autodeploy mode.

3. using "asadmin osgi install" command

Although I do not encourge to use the way, I still need to mention it. For my wab, I can use the following command,

>asadmin osgi start file:///E:/glassfishdev/readworldosgijavaee/helloworldwab/target/helloworldwab-1.0-SNAPSHOT.war

If you do not start the bundle immediately while deploying the wab, you only use "asadmin osgi install ....".

So far, you maybe ask me the difference among the above three ways and how I should use them rightly?

Basiclly, My consideration is as following:

 "asadmin deploy --type=osgi" command is very orthodox, and is borned for glassfish osgi-javaee :)

In most cases, I use the way for osgi-javaee application. However , while deploying some *big * osgi bundles(eg. vaadin, ...),  deployment time will be very slow, and I have created an issue and wish team will improve it. So, if being the case, please use autodeploy way. I do not suggest using "asadmin osgi install..." except in some special cases(eg. glassfish issue's debugging...), and after all, I think that "asadmin osgi ..." is more oriented into osgi developers.

Understanding and Reviewing OSGi RFC 193-CDI Integration Draft

Today, I  found OSGi RFC 193-CDI Integration Draft  has been available , and this is a very exciting news, and I have waited for long time, :).

I have spent two hours on understanding and reviewing the draft, and I want to share my some point of view with you. Maybe  some of these viewpoints are a litter childish.

Firstly,  I will repeat to say what the draft does:

[RFC 193]

"While OSGi services are very powerful, consuming them has been a challenge for many OSGi users. There have been a number of solutions to this problem both in OSGi specifications as well as in non-standardized technologies. OSGi Declarative Services and Blueprint are popular specifications in this area, however they provide new programming models that users need to learn. As of JavaEE 6, CDI (JSR 299) is included as a standard injection technology for JavaEE components. The CDI programming model seems suitable for interaction with the OSGi service layer as well and has the benefit that developers who are familiar with CDI don't need to learn a new technology in order to interact with the OSGi service registry."

Simply saying,  the goal of OSGi/CDI Integration is to,

1) [More standardized]closely combining with JavaEE 6, 7,....

2) Reducing the learing burden of JavaEE developer who will come into OSGi world

3) Simplyfying programming model using JavaEE's power

Nextly, let us start this reviewing travel,

1 About RFC 193's reference implementation

Maybe being not final , the draft has been not stated  reference implementation related things. However, I have a strong feeling that  Weld-OSGi has some possibility being RFC 193's reference implementation.

Why I mentioned the issue?

If Weld-OSGi finally is the RFC 193's reference implementation, whether meaning Glassfish OSGi/CDI will be abandoned, instead, using Weld-OSGi.

2 About OSGi/CDI  API's Standardization

In the whole draft, I only found the following annotation from "5 Technical Solution",

1) @OSGiComponent

2) @OSGiService

3) a group of dependency injection callbacks

4) @OSGiServiceFilter

Frankly speaking, I like the "5 Technical Solution" very much! , However, I have a question as following:

"where are these APIs's prefix(package name) ? And whether there is a plan to publish these apis's full name? And put these apis into which OSGi version? "

Of course, there is another possiblity that OSGi EEG will leave these to OSGi/CDI providers.

3 About "4.1 Functional Requirements"

1)  the most important requirement of them I think

"CDI002 – The specification MUST make it possible to access all CDI managed beans from the OSGi Service Registry."

How to understand it correctly?

I have seen many times that an user has such a requirement from glassfish community.

Eg.  today's afternoon, Sahoo and I together invesitigated an OSGi/CDI issue   from glassfish community. Let us see how the user does,

He has a bundle called "A" as OSGi Service provider, and I list the logic of one of publishing OSGi Service,

@Named
@RequestScoped
@Log
@TimeStamp
@Component(name = "Item Processor")
@Service
public class ItemProcessor implements ItemProcessorSvc {

    @Inject
    @Demo
    private ItemDao itemDao;
    @Inject
    private ItemValidator itemValidator;
    @Inject
    @Notify
    private ItemErrorHandler itemErrorHandler;
    @Inject
    private Event<Item> eventProcessor;

...

Here, he uses Declarative Services to register ItemProcessor as an OSGi service, and being more important, he wishes that before registering, the instance of ItemProcessor can inject ItemDao using normal CDI way. However,  up to now,  I have not still seen this SCR-CDI's bridge, so, after registering ItemProcessor as an OSGi service, once you use @OSGiService to obtain the service and try to invoke  ItemProcessor's method, you will see a NPE happen because at the point, itemDao field of this ItemProcessor service is NULL.

So, not only being Declarative Services , OSGi/CDI integration also needs this bridge  and this is why CDI002 is very important! And just as "2.3 Declarative Services, Blueprint and CDI" saying:

"...It also makes sense to consider creating similar complementary relationship between their containers and the CDI container for runtime injection processing..."

2) not understanding requirements

Among these function requirements, there are some requirements I can not still understand as following:

- "CDI006 – The specification MUST make it possible to write a portable CDI jar that runs both in JavaEE as well as in OSGi."

I want to ask that here, "portable" has any special meaning?

- "CDI007 – The specification MUST consider the thread-safety issues that can arise when migrating CDI beans from JavaEE to OSGi."

Here,  I think that Specification should state a concrete scene about "thread-safety issues" .

4 About "5 Technical Solution"

1) a miss?

I found that on the image "Publish CDI bean as OSGi Service", whether "@OSGiService" should be "OSGiComponent" or not?

2)  about "Dependency injection callbacks"

I like these callbacks very much because this made our applications more felixable and dynamical. I have seen many times that  an user wants to use such callbacks to dynamiclly extend his application rather than re-deploying the whole application. However, it seems to miss a group of callback apis - Service Updating Callback Apis

Finally, I felt that the draft has forward a big step to the final!

Thanks OSGi EEG's hard effort!

Glassfish OSGi-JavaEE Part3 : Glassfish OSGi Web Container - deploying a wab

If you have not read Part1 and Part2, please first read them.

In this part,  we will introduce Glassfish OSGi Web Container  and start our travel from creating a wab using maven and deploying it into glassfish v4. In the next parts, I will look into Glassfish OSGi Web Container in depth and  introduce which features Glassfish OSGi Web Container has providered us with and which features we are implementing.

As is mentioned in Part1, Glassfish OSGi Web Container is implemented in fighterfish/module/osgi-web-container. Firstly, let us see the responsibility of Glassfish OSGi Web Container or simply saying, it does what?

[My Understanding]

"Glassfish OSGi Web Container is used for implementing OSGi R4 version 4.2 Enterprise Specification - 128 Web Applications Specification, and the Web Applications Specification is mainly used for defining and supporting a new OSGi bundle form called Web Application Bundle(WAB) which can run in both an OSGi bundle context and a Java EE context"

Simply saying, according to GF-OSGi-Features , When a web application is packaged and deployed as an OSGi bundle, it is called a Web Application Bundle(WAB).

Next, I will start to explore Glassfish OSGi Web Container from creating a wab sample.

In the sample, I will create a bundle activator used for demostrating that while deploying the wab into Glassfish OSGi context, the activator will be invoked, at the same time, I will also create a servlet using Servlet 3.0 to make the wab can run in JavaEE context while deploying the wab into Glassfish JavaEE context.  In addition,  for my favorite, I will use Maven + Eclipse to develop such a wab.

1. Creating a wab called "helloworldwab"

1) generating a simple maven project using the following directive

mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.fujitsu.cn.samples.osgi.helloworldwab -DartifactId=helloworldwab

2) adding dependencies into pom.xml

Because the sample will import org.osgi.framework.BundleActivator and javax.servlet.*  and javax.servlet.http.*, we must add these dependencies into pom.xml

 <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
       <groupId>org.osgi</groupId>
       <artifactId>org.osgi.core</artifactId>
       <version>4.2.0</version>
       <scope>provided</scope>
    </dependency>
    <dependency>
       <groupId>javax</groupId>
       <artifactId>javaee-api</artifactId>
       <version>6.0</version>
       <scope>provided</scope>
    </dependency>
  </dependencies>

3) generating eclipse related project file to import the maven project into eclipse

executing "mvn eclipse:eclipse"

4) importing the maven project into eclipse

[File]->[Import]->"Existing Projects into Workspace"

5) making App class (you can change into more friend name) generated by maven to implement BundleActivator interface

6) Creating a Servlet called "HelloWorldServlet"

Adding the following code into this Servlet.

7) Preparing to package the wab

① modify pom to change "<packaging>jar</packaging>" into "<packaging>war</packaging>"

We need war form rather than common jar.

② adding two plugins into pom's <build> as following:

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.felix</groupId>
                <artifactId>maven-bundle-plugin</artifactId>
                <version>2.3.7</version>
                <extensions>true</extensions>
                <configuration>
                    <supportedProjectTypes>
                        <supportedProjectType>ejb</supportedProjectType>
                        <supportedProjectType>war</supportedProjectType>
                        <supportedProjectType>bundle</supportedProjectType>
                        <supportedProjectType>jar</supportedProjectType>
                    </supportedProjectTypes>
                    <instructions>
                        <!-- Specify elements to add to MANIFEST.MF -->
                        <Web-ContextPath>/wabclient</Web-ContextPath>
                        <!-- By default, nothing is exported -->
                        <Export-Package>!*</Export-Package>
                        <Bundle-Activator>com.fujitsu.cn.samples.osgi.helloworldwab.App</Bundle-Activator>
                    </instructions>
                </configuration>
                <executions>
                    <execution>
                        <id>bundle-manifest</id>
                        <phase>process-classes</phase>
                        <goals>
                            <goal>manifest</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>bundle-install</id>
                        <phase>install</phase>
                        <goals>
                            <goal>install</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-war-plugin</artifactId>
                <version>2.3</version>
                <configuration>
                    <archive>
                        <!-- add bundle plugin generated manifest to the war -->
                        <manifestFile>
                            ${project.build.outputDirectory}/META-INF/MANIFEST.MF
                        </manifestFile>
                        <!-- For some reason, adding Bundle-ClassPath in maven-bundle-plugin
                            confuses that plugin and it generates wrong Import-Package, etc. So, we generate
                            it here. -->
                        <manifestEntries>
                            <Bundle-ClassPath>WEB-INF/classes/</Bundle-ClassPath>
                        </manifestEntries>
                    </archive>
                    <failOnMissingWebXml>false</failOnMissingWebXml>
                </configuration>
            </plugin>
        </plugins>
    </build>

This is the most critical step for packaging a wab successfully. There are some notes as following:

- we use maven-bundle-plugin to package a OSGi bundle rather than common jar

we also need to add a series of "instructions" to package the wab rightly, for example,

<Web-ContextPath> tells us that the war is a wab, and <Bundle-Activator> tells us that the wab has an activator which will be invoked by OSGi runtime while starting the wab.

About detailed "instructions" ,  please seeing apache-felix-maven-bundle-plugin .

- we also use maven-war-plugin to package a war deployment structure because virtually a wab is also a war.

8) installing the wab

Backing to command shell, we start to install the wab by executing the following command,

mvn clean install

After executing the above command, you will see an artifact called "helloworldwab-1.0-SNAPSHOT.war" in target directory. If you unzip the war, you will find that in MANIFEST.MF, the following contents will be generated,

Manifest-Version: 1.0
Bundle-ClassPath: WEB-INF/classes/
Built-By: Administrator
Tool: Bnd-1.50.0
Bundle-Name: helloworldwab
Created-By: Apache Maven Bundle Plugin
Web-ContextPath: /wabclient
Build-Jdk: 1.7.0_09
Bundle-Version: 1.0.0.SNAPSHOT
Bnd-LastModified: 1363100030484
Bundle-ManifestVersion: 2
Bundle-Activator: com.fujitsu.cn.samples.osgi.helloworldwab.App
Import-Package: javax.servlet,javax.servlet.annotation,javax.servlet.h
 ttp,org.osgi.framework;version="[1.5,2)"
Bundle-SymbolicName: com.fujitsu.cn.samples.osgi.helloworldwab
Archiver-Version: Plexus Archiver

Congratulations! you have installed a right wab. And next, we will deploy the wab into Glassfish v4.

2. Deploying the wab into Glassfish v4

1) Preparing a Glassfish v4 distro

You have two ways to obtain a glassfish v4 distro, because currently, glassfish v4 is still in development, you can only obtain by

① http://dlc.sun.com.edgesuite.net/glassfish/4.0/promoted/

②  building a v4 SNAPSHOT according to https://wikis.oracle.com/display/GlassFish/FullBuildInstructions

2) starting glassfish domain

Opening a command shell and executing the following command to start glassfish domain

asadmin start-domain domain1

3) using deploy command to deploy the wab into Glassfish domain

asadmin deploy --type=osgi helloworldwab-1.0-SNAPSHOT.war

Noting: you must add "--type=osgi" , otherwise, you are deploying a common war rather than wab.

After deploying successfully, you should see the following in server.log

"helloworldwab has been in OSGi context!"

3. Accessing the wab from your favorate broswer

eg.  openning firefox, and accessing "http://localhost:8080/wabclient/HelloWorldServlet", you will see " Hello, This is a Web Application Bundle!"

Glassfish OSGi-JavaEE Part2 : building a fighterfish's development env and how to do a contribution

In the Part1 , I introduced Glassfish OSGi-JavaEE and Fighterfish , simply saying, Fighterfish is the implementation of Glassfish OSGi-JavaEE. In addition, I also introduced how to build Fighterfish modules from its trunk.

In the Part2, I will tell you how to build a fighterfish's development env including debugging, at the same time, I will also tell you how to contribute a patch for a fighterfish's module successfully. The part will benifit to those guys who are interested in Glassfish OSGi-JavaEE and have a plan to contribute the field.

1. How to build a fighterfish's development env with eclipse and maven

If you are a NetBeans or IntelliJ IDEA fans, I am sorry that the following contents maybe disappointed you, because I have been always using Eclipse.

prerequisite: needing the following tools

1） Eclipse Indigo or other versions

2) Maven 3.0.4

Note: I suggest you do not use m2e plugin, because once you use the plugin, maybe you will meet some curious problems while you import fighterfish modules into Eclipse and try to build them.

Now, let us try to build a development envirioment.

[Step1] Building fighterfish's modules

Please according to Part1 , first we need to do a build for  fighterfish's modules. Although you can ignore the step, I suggest you do it , for example, maybe there is a scene as following:

I wish to contribute and update osgi-web-container module which depends on osgi-javaee-base 1.0.0,  if you need not to update osgi-javaee-base, you can ignore the step, however, if you also need to update osgi-javaee-base,  first you must build osgi-javaee-base, then you need to modify osgi-web-container's pom and set osgi-javaee-base dependency version into 1.0.6-SNAPSHOT.

[Step2] associating maven with eclipse

Because we use maven to manage dependencies , we must make eclipse workspace to recognise maven, here, there are two ways:

1) manually add M2_REPO into Eclipse( Preferences→ Java → Build Path → ClassPath Variables)

2)executing the following command from your shell

mvn -Declipse.workspace=<Your workspace> eclipse:add-maven-repo

[Step3] generating eclipse related project file and classpath file 

This is a very critical step used for importing a fighterfish's module.

Entering the fighterfish/module or some module of fighterfish/module, Executing the following command from your shell,

mvn eclipse:eclipse

[Step4] importing a fighterfish module into eclipse

If Step3 is successful, you can open eclipse and import a fighterfish module into eclipse. The following is a sample(osgi-javaee-base) from my eclipse env.

[Step5] building the imported fighterfish  module

Once finishing step4, you can programe java codes and elaborate your ability and wisdom！ However, if you want to build an artifact of the module, you still need to go back your shell and execute "mvn clean install". Maybe you think that it is not inconvenientable compared with other maven eclipse plugin(eg. m2e), however, I think this can be acceptable , :).

2. How to debug a fighterfish's module in eclipse

If you obey with 1, you should toword a success road to contribute. Then, you will meet a problem : how I can debug a fighterfish's module , especially while I am resolving a bug from some fighterfish's module?

It is a good question!

The question is also related to how to debug glassfish itself. Basically, this needs to divide two scene as following,

1) debugging fighterfish module after starting glassfish domain

The scene is a normal case and you only need to do the following:

executing "asadmin start-domain --debug"

This will make glassfish listen 9009(default port) port in a unsuspend way, then, you create a remote debug configuration in eclipse and attach the 9009 port. It is very simple!

2) debugging fighterfish module starting logic while starting glassfish domain

Firstly,  you need to config domain.xml and find the following line:

 <java-config debug-options="-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=9009" system-classpath="" classpath-suffix="">

and, modify "suspend=n" into "suspend=y".

then, executing "asadmin start-domain --debug",

finally, you create a remote debug configuration in eclipse and attach the 9009 port.

Now, you can start the travle of debugging fighterfish and before debugging, you can add related project's source into eclipse and attach these project's source into the remote debug configuration because this will be very convenientable while debugging.

3. How to contribute a patch for a fighterfish's module successfully

Now, I have been one of glassfish team's developers and looking back the past contribution, I have much thought, and in this part, I want to tell you the most important thing→"How to contribute a patch for a fighterfish's module successfully" if you want to aim to be a developer of glassfish team or wish your patch can be acceptable more quickly.

Here, we need to do several things,

1) re-produce the scene of this bug or feature or task

re-producing the scene of this bug or feature or task from glassfish jira as possible, and noting that if you have found and confirmed a new bug or have an outstanding idea about some module, you can file a jira issue in  glassfish jira . If being the latter , you must write re-producing steps carefully because this will be very important for other people of community.

2) finding the reason, and you'd better do a initial of detailed investigation

If you have more time and aim to resolve the issue yourself, I wish you can do a detaild investigation.  Frankly speaking,  the investigation is my best love because while I start to do an investigation, I felt that I am a detective and try to find each useable glue for the issue's true reason and fixing method.

3) try to fix the issue and supply a patch

Based on 2), you can try to fix the issue and supply a patch, here, there are some experience to share with you. Because fighterfish is a matured project, and most modules use some same design patterns(I will introduce you in next articles), you'd better stick to these design guidelines and not re-invent a new wheel! At the same time, I wish you can stick to some programming rules , and this is not very difficult because you can do it by seeing existed sources carefully.

Noting that because currently, glassfish jira is in updating and does not allow uploading any attachment,  if you have a patch, please send it into dev@glassfish.java.net or sanjeeb.sahoo@oracle.com (Sahoo is fighterfish's leader), of course, you can also send it to me, :)

4) modify your patch based on community's review

Normally,  you will receive a patch's review result, and you need to modify your patch until it is no any problem. Please remembering not to foget adding comments and modifying copyright. Here, I need to say a point about copyright and I have ever made a mistake.

For example, the original file has a copyright as following:

...

* Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.

...

While you modify the file, you should modify the above copyright into the following:

...

* Copyright (c) 2012-2013 Oracle and/or its affiliates. All rights reserved.

...

★I have ever made a mistake as following:

...

* Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved.

...

5) doing a fighterfish it test

This step is the most critical step of above steps, because fighterfish it test is to protect your patch from casuing some regression, how to do it?

Firstly, entering fighterfish/test directory from your shell, and executing the following command to build util and app modules(note,  you also need to build fighterfish/sample because fighterfish it test needs some samples's artifacts)

Secondly, entering fighterfish/it directory from your shell, and executing the following command

mvn clean test -Dglassfish.home=/.../.../glassfish4/glassfish

Here, glassfish.home property must be set to specify a valid glassfish distro, if you am doing a patch for some fighterfish patch, you must first put artifact of the fighterfish module with your patch into /.../.../glassfish4/glassfish/modules/autostart to override the original artifact, then execute the above test command.

In the next parts, I will start to share you with Glassfish OSGi-JavaEE's important features and new features brought into current v4,  and look into fighterfish in depth.

Glassfish OSGi-JavaEE Part1 : Introducing Fighterfish sub-project and building

Since 2012, I start to paly with Glassfish OSGi-JavaEE, and this is a unique position in Glassfish. Since 2009 - the first release of Glassfish v3,  Glassfish OSGi-JavaEE came into being.

Fistly, let us see the definition of Glassfish OSGi-JavaEE:

"GlassFish Server enables interaction between OSGi services and Java EE components. This interaction is bi-directional. On one hand, OSGi services managed by OSGi framework can invoke Java EE components managed by Java EE container. On the other hand, Java EE components managed by Java EE container can invoke  OSGi services managed by OSGi framework. "

If you are careful enough, you will find that in Glassfish v3's distro, there is a special directory called "autostart" which is located in "glassfish/modules" and the jars or OSGi bundles as following implemeting Glassfish OSGi-JavaEE features are located in the "autostart" directory. 

- osgi-javaee-base.jar

- osgi-web-container.jar

- osgi-ejb-container.jar

- osgi-jdbc.jar

- osgi-jpa.jar

- osgi-http.jar

- osgi-jta.jar

- osgi-cdi.jar

- osgi-ee-resources.jar

The above nine jar files are implemented by a glassfish sub-project called "Fighterfish". While I start to play with Fighterfish,  I am very curious the name of Fighterfish. Although I have not ask Sahoo(Fighterfish's leader, a famous developer of Glassfish Team) why uses the name, I guess that compared with Glassfish, Fighterfish can aim to make glassfish inject more energies and more competitive strength while competing with other application servers.  The approach should be OSGi & OSGi-JavaEE!

Backing to 2012.7,  while I start to contribute Fighterfish(maybe you want to ask me why seclecting Fighterfish,  because I like both OSGi and JavaEE!),  the first thing to do is to check out Fighterfish's source and building it,  OK,  my story begins with here,

Noting: you can directly see the document[1] from the Oracle Glassfish Wiki:

[1] https://wikis.oracle.com/display/GlassFish/FighterFish+Development+Process

However,  if you think that contents of the above link have a litter long,  please continue to see the following

1.  check out fighterfish's source from trunk

prerequisite: needing the following tools

1) JDK 6 or JDK 7

2) SVN  Client Tool

Because my OS is WindowsXP, I use TortoiseSVN, a very great tool.

To check out source from trunk, please using the following svn url:

svn checkout https://svn.java.net/svn/glassfish~svn/trunk/fighterfish

Noting: if you are behind in your corporation's proxy server, you should config your TortoiseSVN's network setting.

2.  Building the fighterfish trunk

Here, what I said "building the fighterfish trunk" means to build "fighterfish/module", because fighterfish/module implements the above nine jars(osgi-*.jar)  which are located in the "autostart" directory.

prerequisite: needing the following tools

1) Maven 3.0.4

You can use other versions of Maven such as maven 2.2.1, however, I use maven 3.0.4, a latest maven 3.x release.

2) (Optional)Current Glassfish v4 SnapShot

Why I said a Glassfish Distro is optional? Here has two reasons:

- if you tight wish Glassfish v4's development, for example, you find a OSGi-JavaEE's regression on current Glassfish v4 SnapShot, you should have a current Glassfish v4 SnapShot.

- if you maintance a Glassfish v3's release, or plan to investigate a OSGi-JavaEE's bug in Glassfish v3, you need not to have a current Glassfish v4 SnapShot.  Please remembering such a fact: the most of Fighterfish's modules are compatible with Glassfish v3 and v4 except for the osgi-ee-resources, that is to say, the most of Fighterfish's modules do not depend on Glassfish v4's API.

- (★)for osgi-ee-resources, if you build it or build the whole fighterfish/module,  you will meet the following error,

...

Failure to find org.glassfish.main.jdbc:jdbc-config:jar:4.0-b73 in
http://download.eclipse.org/rt/eclipselink/maven.repo/ was cached in the
local repository

...

This is because currently, repo1 maven repository has not 4.0-b73 related artifacts(I have reported the error into community), so, if you am playing with osgi-ee-resources, you have two choices:

①manually install jdbc-config-4.0-b73.jar and connectors-internal-api-4.0-b73.jar from the following repo:

https://maven.java.net/content/groups/promoted/org/glassfish/main/

installing directive is as following(eg. jdbc-config-4.0-b73.jar):

mvn install:install-file -DgroupId=org.glassfish.main.jdbc -DartifactId=jdbc-config -Dversion=4.0-b73 -Dpackaging=jar -Dfile=/.../.../jdbc-config-4.0-b73.jar

②you can also modify osgi-ee-resources's pom and replace 4.0-b73 with 4.0-SNAPSHOT if you want to use the latest Glassfish Trunk API.

3) config maven's setting.xml

For me (a glassfish outside contributor), I will config my maven's setting.xml and add the following:

    <mirror>
      <id>maven-central</id>
      <url>http://repo1.maven.org/maven2/</url>
      <mirrorOf>*,!eclipselink.repository</mirrorOf>
    </mirror>

The mirror also applies in Glassfish Main's building. If you come from Oracle itself, you'd better do liking [1].

To build the fighterfish's module, please execute the following command from your shell:

> set MAVEN_OPTS = -Xmx512m -XX:MaxPermSize=256m

> mvn -DskipTests=true clean install

Note: you must set MAVEN_OPTS and if you do not set the env varible, you can get an out of memory exception while executing maven building.

OK,  about  "testing and looking fighterfish modules in depth", I will put the next part.

Refrence:

1. GF-OSGi-Features

2. FighterFish Development Process