Content available at: http://blogs.sun.com/arungupta/entry/totd_130_invoking_a_osgi
Content available at: http://blogs.sun.com/arungupta/entry/totd_129_managed_beans_1
In my last blog I described the generic user procedures as used in CAFE.
These procedures can be used for registration and various parts of presence.
In this instalment I will go a bit deeper into the presence related user procedures, showing how to publish presence information on behalf of a user and subscribe to presence information.
And since presence information in CAFE is (currently) bound to the groups, I'll also show a bit of the group management.
Content available at: http://blogs.sun.com/arungupta/entry/totd_126_creating_an_osgi
Content available at: http://blogs.sun.com/arungupta/entry/totd_127_embedding_glassfish_in
This post tries to explain the seach API that has been introduced in SailFin CAFE v1 b28. The API allows application developers to search for communications that were created earlier, thereby removing the need for applications to store context information for these objects by themselves.
Content available at: http://blogs.sun.com/arungupta/entry/java_ee_6_glassfish_netbeans
Content available at: http://blogs.sun.com/arungupta/entry/totd_125_creating_an_osgi
Content available at: http://blogs.sun.com/arungupta/entry/day_2_tech_days_2010
<p>I am working on rewriting a set of labs for our intermediate students at
SJSU. Version control is something that everyone with a CS degree is pretty
much expected to know these days. But instead of revising my old Subversion
lab, I decided to plunge into Mercurial. Of course, for team work, we need a server. I installed Mercurial onto a
donated Sun server running OpenSolaris and GlassFish. Installation was a bit
off the beaten track, so here are the directions.</p>
Extending GlassFish Ceritificate Realm
Secure Applications with GlassFish V3 Embedded Mode
This article introduces GlassFish CLI or command line administration console. GlassFish provides several administration channels; one of them is the command line administration interface or CLI from now on. The CLI has many unique features which make it very convenient for command line advocates and new administrators which like to get familiar with CLI and use it in the daily basis. The CLI allows us to manage, administrate, and monitor any resources which application server exposes to the administrators.
In this entry we discuss what Application Server Management Extension (AMX) and Java Management Extensions (JMX) are, how we can use them to develop custom administration, management and monitoring solutions for GlassFish v3. The article contains tens of diagrams and samples.
This is the second part of a larger setup which explain how to extend GlassFish CLI (Command Line interface , asadmin functionalities) and GlassFish Administration Console (Web Console). This Second part assume that you read the first part and you are ready to get your hands dirty with the coding and deployment.
Here is an example of OSGi/JMS/MDB comprising of two OSGi bundles deployed in GlassFish:
a) A JMS message producer bundle
b) A JMS message consumer bundle
Content available at: http://blogs.sun.com/arungupta/entry/totd_128_ejbcontainer_createejbcontainer_embedded
I will wrap up my experience at eclipsecon. I will also point to my slides and sample source code that shows how to develop EJBs as OSGi service.
In this post I will share my recent findings about Container Dependency Injection in Java EE 6, in particular how to decouple the processing threads of event producers and event consumers.
Java EE 6 introduces a very nice dependency injection framework (CDI) that has superb support for the Observer pattern in the form of event broadcasting.
An Event in CDI is just a regular POJO:
Java Web Services and XML
Recently a user in GlassFish forum asked about developing JAX-WS web service in an OSGi bundle. Here is a complete sample demonstrating the same. You can download it from here.
As the above diagram shows, we have three components, viz:
1) osgi-service.jar: This is an OSGi bundle which provides a service to other bundles. It contains two POJOs, viz:
a) an interface called sahoo.hybridapp.jaxws1.service.Watch
b) an implementation of the same interface called sahoo.hybridapp.jaxws1.service.WatchImpl.
This bundle also contains a bundle activator called sahoo.hybridapp.jaxws1.service.Activator, which is responsible for registering an instance of WatchImpl in OSGi service registry.
2) web-service.war: This is a Web Application Bundle. A Web Application Bundle is a hybrid application - it's both a Java EE archive as well as an OSGi bundle. In this case, it is a war file as well as an OSGi bundle. It's a war file, because it contains a Servlet based JAX-WS end point. It's an OSGi bundle, because we want to make use of OSGi service in the implementation of our web service. It contains a single class called sahoo.hybridapp.jaxws1.webservice.WatchWebService which is defined like this:
The MANIFEST.MF of web-service.war looks like this:
3) web-service-client.jar: This is a plain jar file which makes use of JAX-WS stack of Java SE environment to invoke our web service. It has a single class called sahoo.hybridapp.jaxws1.webserviceclient.Main. The rest of the classes that are part of this jar are generated by wsdl compiler as part of build.
How to build, deploy and test:
Step 1: Start GlassFish
Step 2: Build and deploy the service bundles
mvn clean install
This will produce two OSGi bundles called osgi-service/target/osgi-service.jar and web-service/target/web-service.war. Deploy these two OSGi bundles to GlassFish by simply copying them to domain1/autodeploy/bundles/ dir as shown below:
cp osgi-service/target/osgi-service.jar web-service/target/web-service.war $glassfish.home/domains/domain1/autodeploy/bundles/
GlassFish will automatically detect that web-service.war is a WAB and will perform necessary deployment of EE artifacts as a result of which a web service end point will be available. You can see something like this appearing in server.log:
WS00018: Webservice Endpoint deployed
WatchWebService listening at address at http://localhost:8080/hybridapp.jaxws1.web-service/WatchWebServiceService
Step 3: Build and run the client
Once the web service is available, run
mvn -f web-service-client/pom.xml
to build web-service-client.jar. This is because the WSDL url, as specified in web-service-client/pom.xml, is not available until the web service is deployed.
To test, simple run:
java -jar web-service-client.jar
You shall see it will print the current time as obtained from the web service which in turn obtrains it from the OSGi service.
Enjoy developing OSGi enabled Java EE applications in GlassFish.