My Wiki

JBoss Community Asylum - Cool place to get JBoss Community podcasts

2009-09-25T06:52:00.000-07:00

It's been a while since i last blogged. Mainly because there wasn't anything interesting/useful that was worth sharing here. However, one of the news worth sharing, is the launch of JBoss Community Asylum. It's been started by Max R Andersen (JBoss tooling), Emmanuel Bernard (Hibernate team) and Michael Neale (Drools team) and will be sharing podcasts related to JBoss Community and its projects: news, interviews etc.

The first podcast has already been uploaded. So for those who missed the recent JBoss World event, this first podcast is an summary of what happened there. So don't miss it, you can get it here

And stay tuned to that site for more such podcasts in the near future!

JBossAS now has an admin-console!

2009-04-30T00:02:00.000-07:00

JBoss AS users have always asked why JBoss does not have an admin console. Personally, i have always liked working directly on the configuration files without needing any web application or any other tool for doing the same. That's because i like spending more and more time on the AS. But for users who want to just get things done without having to worry about how it is done or which file gets placed where and want to manage the deployments through a web application, a decent admin console was always a neccessity. Its good news now for all JBoss AS users - starting 5.1.0.CR1 version, JBoss AS now has an excellent admin console!

I decided to give it a try, during this weekend, to see what features it provides. This article is just to give you some idea about what the admin-console has. The best place to look for all other details and feature list of the admin-console, is the Embedded Jopr project page. So here's an account of what i found about the admin-console.

The admin console is available by default in the "default" and "all" server configurations. The application is available as a WAR file "admin-console.war" in the deploy folder of these configurations. You can access the admin-console at the following URL http://localhost:8080/admin-console. By default, the username for the application is "admin" and the password is "admin".

Once you login to the admin-console, you will notice a list of menu items on the left hand side of the screen. The right hand side of the screen is a multi-tabbed details page. So let's click on the "Applications" menu item on the left hand side menu. This shows a list of all applications on the server. Each of these applications is categorized based on the type of the application. Some of the categories are : EJB2.x application, EJB3.x application, WAR, EAR, MC beans. There's also Embedded WARs - these are WAR files which are deployed within an EAR file. Apart from applications, the admin-console also displays resources like JMS factories, JMS destinations (queues/topics), datasources. For each of these applications and resources, the admin-console shows the status (UP/DOWN) of those applications/resources. You can delete existing resources or applications by clicking on the "Delete" button on the details page.

The admin-console allows you to deploy new applications (WAR, EAR etc...) and also add new resources. So let's see how to deploy an EAR file. On the left hand side menu, click on the Enterprise Application (EARs) link under the Applications. Then on the details page, you will notice a "Add a new resource" button. Click on it. Use the Browse button to select the EAR you want to deploy. This page also gives you an option to deploy the EAR either as an archive or in a exploded format. Select appropriate option and click Continue. That's it, if the application is deployed successfully, you will see an appropriate message and also the status of the application will be shown as "UP". For all those who want to deploy applications in the traditional way (copying to deploy folder), you can still do it. The admin-console dynamically updates it list of deployed applications and on the next refresh, you will notice your application being listed.

As i mentioned earlier, the details page is a multi-tabbed page. It has a Metrics tab, Control tab, Configuration tab etc... So let's see what the "Control" tab can be used for. Select the Enterprise Application link (from the left hand menu) and drill down to the application of your choice. Then click on the "Control" tab. You will notice options to "Start", "Stop" and "Restart" the application. The other tabs like "Configuration", "Metrics" show many details about the selected application or resource.

Overall, the admin-console is a great addition to JBoss AS and provides that you expect from a decent admin-console. Users who have long waited for such an admin-console in JBoss will finally get what they asked for! So go to the JBossAS download page and get the latest 5.1.0.CR1 version and start playing with the console.

As always, if you have any suggestions or issues to report, feel free to do so in the Embedded Jopr forum.

JBoss EJB3 tutorials and docs

2009-04-07T01:09:00.000-07:00

I thought i will blog this, since i have been seeing many of the community members looking for some documentation or tutorials for EJB3 on JBoss. Obviously, for anyone who's trying to learn a new technology, the best place to start will be the tutorials. Many of you might be already aware that the new JBossAS-5.x series have been released to the community. Just recently we uploaded a completely new set of EJB3 tutorials and reference documentation targeted for JBossAS-5. These tutorials and reference documentation is available here. The earlier set of tutorials which are targeted for AS-4.x are available here.

The new set of tutorials have been modified to work against AS5. The changes mainly include changes to deployment descriptors or any JBoss specific EJB3 features. The complete source code for the tutorials is available for download at the same URL.

The important point to note is that these tutorials will be maintained to work against the latest release of EJB3 plugin. So what is EJB3 plugin? JBossAS-5 ships with EJB3 support by default. As you all know, the JBoss EJB3 project and the JBoss AS project are maintained separately and as such have their own release cycles. So what happens if we introduced something new in EJB3 or do a major bug fix for the community in EJB3 project? How do we make it available to the community who use EJB3 support provided by AS5? That's where the EJB3 plugin comes in picture. The EJB3 plugin provides a mechanism where you can patch newer versions of EJB3 into AS5. This way, if there are any major bug fixes or enhancements you are waiting for from the EJB3 community, then you can use the EJB3 plugin to patch it in AS5.

The next question would be, when and where do i get the EJB3 plugin for the AS. EJB3 project has come up with a release cycle where, every 2nd and 4th Friday of the month there will be a EJB3 release. These releases are downloadable at the JBoss EJB3 download page . So how do you use this plugin against the AS? It's pretty simple. All you need is:

- JBossAS-5 installation
- Ant 1.7

Download the plugin which is nothing but a jar file and run the following command


java -jar jboss-ejb3-plugin-x.x.x-installer.jar < path to JBossAS5.x >

Note that jboss-ejb3-plugin-x.x.x-installer.jar is the name of the jar file you downloaded.

So that gives you an idea about what the plugin is. Coming back to the EJB3 tutorials, I mentioned earlier that these tutorials are maintained to work against the latest release of EJB3 plugin. What this means is, you won't find a tutorial in a broken state (tutorials that are no longer running). The tutorials are tested against every release of the EJB3 plugin. So if something in the tutorials breaks, then that's fixed at the right place before they are released to the community.

If anyone has any suggestions or questions about the tutorials or the EJB3 docs, feel free to start a discussion in the JBoss EJB3 forum

JBossAS 5.0.1 GA released

2009-02-24T00:54:00.000-08:00

JBossAS-5.0.1 GA has been released today. The download is available on the JBoss download site. One of the major issues that has been fixed in this release is the one that was reported in the community and was related to "tmp" file handling of deployments by VFS.

Recognition to community contributors - JBoss Community Leadership Awards

2009-01-14T04:04:00.000-08:00

It's a well known fact that community support for an open source project is always necessary for the growth of the project. Support can be in any form - documentation, bug fixes, feature enhancements, active participation in the forums etc... JBoss has taken the initiative to recognize such community users who have contributed in a great way, towards the growth of various projects hosted at JBoss. The JBoss Community Leadership Awards aims at recognizing such community members. There are various categories for the awards - checkout the poll page. You can cast your vote under any of those categories. This is a chance to cast your vote for those who might have helped you, in some way or the other, while using projects hosted at JBoss :)

JBossAS-5.0 goes GA

2008-12-06T06:09:00.000-08:00

JBossAS-5.0 GA community edition has been released a few days back!!! Many of you might be knowing that the JBoss-5.0 development was going on for a few years now. After 4 Betas and 2 CRs the application server is now GA. JBossAS-5.0 GA complies with JavaEE5.

Some of you who keep an watch on the JBoss forums and mailing lists, might already be aware that JBoss-5 was completely rearchitectured. There have been a variety of architectural changes that have been introduced in JBoss-5. So what does this mean to a developer who's been using JBoss-4.x so far? The purpose of this article is to highlight the changes that have come in as part of JBoss-5. I won't be dwelling a lot into the technical details (i will leave it to the experts), but will try to give an overview of changes in this version from JBoss-4.x. This article is aimed at making you aware about things to keep in mind when you start using JBoss-5.

So let's start!

1) Additional server profiles/configurations :

JBoss-4.x AS community users will be used to seeing 3 server profiles being shipped by JBoss in the %JBOSS_HOME%/server folder. The "all", "default" and the "minimal". JBoss-5.0 GA adds couple of more profiles to this. Now in JBoss-5 you have "all", "default", "minimal", "web" and "standard".

* The "web" profile is meant to contain services which will allow simple web applications (servlet, jsps) to be deployed. It also has support for JTA, JCA and JPA. Some of you might ask how is it different from the "minimal" configuration. If you look in the deployers folder of "minimal" profile, you will find that there are no deployers available in the "deployers" folder nor any applications in the "deploy" folder. The "minimal" profile is mainly meant for letting the developers decide what services they want to be available. The "minimal" is just an empty profile which the users can build upon depending on their needs, whereas the "web" is a subset of the "default" and allows deploying web applications.

* The "standard" profile is the one against which the tests for JavaEE support were run against.

2) Separation of "deployers" and "deploy" :

If you look in the "deploy" folder of a JBoss-4.x system, you will notice that it contains two types of deployables. Some of the deployables are meant to deploy other applications. For example: The jbossweb.deployer in the deploy folder is actually used for deploying web applications (WAR). With JBoss-5, there is now a clear separation between the deployer and the deployable. You will notice that in JBoss-5, there is a "deployers" folder under each server profile %JBOSS_HOME%/server/< serverName>/deployers. The jbossweb.deployer, which i used as an example earlier, is now in this "deployers" folder along with various other deployers. The actual applications that are to be deployed reside in the "deploy" folder %JBOSS_HOME%/server/< serverName>/deploy.

3) Libraries are now moved to a common/lib folder:

In JBoss-4.x, you will notice that the lib folder under each server profile contains almost the same set of jar files. This obviously leads to increased disk space usage. In JBoss-5.0 GA, these common jar files which are required by all these server profiles is now moved to %JBOSS_HOME%/common/lib folder. This common/lib will act as a parent to all server/< serverName>/lib folders. If you want to add any jar for a specific server profile, then you can add it to the %JBOSS_HOME%/server/< serverName>/lib folder. For example: The database drivers that are required by the datasources can be placed in the server profile specific lib folder (%JBOSS_HOME%/server/< serverName>/lib). With the addition of this new common/lib folder, two new JBoss system properties have been introduced:


 * jboss.common.base.url - This evaluates to ${jboss.home.url}/common
 * jboss.common.lib.url - This evaluates to ${jboss.common.base.url}/lib

All other JBoss system properties available in JBoss-4.x http://www.jboss.org/community/docs/DOC-10730 continue to remain in JBoss-5.

4) For Windows users, its now one step easier to run JBoss as a service :

For JBoss-4.x Windows users, running the server as a service required downloading an appropriate version of JBoss Native and then using the service.bat in the JBoss Native to install the service. In JBoss-5.0 GA, its now one step less. JBossAS comes with JBoss Native installed by default. This way, the user no longer has to download the JBoss Native package separetely. The service.bat for installing the service can be found in the %JBOSS_HOME%/bin folder.

5) New jmx-console :

The jmx-console now comes with a better "professional looking" look :-)

As i mentioned earlier, in this article, i'am going to leave out all the technical details about the changes that have come in JBoss-5. I'll leave it for my next articles, which i plan to do pretty soon after spending some time on this new GA version :-) But in the meantime, JBossAS enthusiasts can start playing with the GA version by downloading it from here

And yes, if you run into any issues using JBossAS-5, feel free to post in the AS-5 dedicated forum here

How to upgrade Hibernate in JBoss

2008-08-20T01:26:00.000-07:00

JBoss comes shipped with Hibernate by default. Upgrading Hibernate is similar to upgrading any other 3rd party library in your application deployed on JBoss. As long as you understand how the classloading works in JBoss, the upgrading should be pretty straightforward.

For a brief (well not so brief) background about classloaders in JBoss, have a look at these wiki articles:

How classloading works in JBoss

How to configure classloaders in JBoss

Once you read through these wiki articles, you will understand that if your application needs to have its own version of a library (does not matter if it is Hibernate or some other 3rd party library), you will have to configure classloader scoping through the xml file.

So why am i writing this stuff all over again, when these two wiki articles have enough details about classloading scoping? Its mainly because of some tricky issues, which have been reported in the JBoss forums, with upgrading Hibernate (specifically to Hibernate version 3.2.6) on JBoss-4.2.x (specifically JBoss-4.2.2 GA). The rest of the article tries to explain these issues and way to fix them. Though this is written to be more oriented towards upgrading Hibernate, whatever has been explained here will apply to almost every 3rd party library upgrade on JBoss.

So let's start then!

Details about the default installation of JBoss-4.2.2 GA:

JBoss-4.2.2 GA ships with

 

Hibernate EntityManager 3.2.1.GA
Hibernate Annotations 3.2.1.GA
Hibernate 3.2.4.sp1

What we intend to do is, upgrade Hibernate to use 3.2.6 GA. Let's assume, we have an EAR which will be deployed to JBoss:



MyApp.ear
 |
 |--- META-INF
 |      |
 |      |
 |      |--- application.xml
 |      | 
 |      |--- jboss-app.xml
 |
 |
 |--- lib
 |    |
 |    |--- [some jar files required by my app]
 |
 |
 |--- MyApp.war

So first step would be package the upgraded Hibernate jar files in the application (MyApp.ear). Its crucial to understand that you have to be absolutely sure that you have packaged all the required hibernate jars and the correct versions of those jars in your application. This Hibernate compatibility matrix will help you in picking up the correct versions. However, you still have to know "which" hibernate jars you need to package in the application.

Based on what i have seen in the forums, the issues faced while upgrading Hibernate were more related to users missing out certain dependent hibernate jar files. Debugging such issues was not very easy since, the errors that got thrown were not simple ClassNotFoundException (which you usually associate with a missing jar). Various errors like ClassCastException, NoSuchMethodException were thrown mainly because Hibernate in this version (3.2.6 GA) refactored a lot of their code to move them to different "projects". For example, the org.hibernate.search package was earlier in the "Hibernate Annotations" project (hibernate-annotations.jar) but with this new release, it was moved to a separate "Hibernate Search" project (hibernate-search.jar). Same applies to org.hibernate.validator package which earlier was in the "Hibernate Annotations" project (hibernate-annotations.jar) but with this new release, it was moved to a separate "Hibernate Validator" project.

So how does it matter if those hibernate packages were moved to a different project (jar)? Here's a very brief explanation of what happens:

- JBoss, in its lib folder, has an older version of Hibernate (3.2.4) and other hibernate related jar files, including the hibernate-annotations.jar. In this version, the hibernate-annotations.jar contained the org.hibernate.search and org.hibernate.validator and various other packages.

- You decide to upgrade Hibernate in your application by packaging the hibernate jars in your application and enabling classloader configuration. You package *only* the latest version of core hibernate jar, the hibernate-annotations.jar and maybe even the hibernate-entitymanager.jar.
Note: You have NOT packaged the hibernate-validator.jar nor the hibernate-search.jar.

- You start JBoss and the server tries to deploy your application. While deploying, for configuring Hibernate, various Hibernate classes are used, which includes the classes belonging to core hibernate jar and also org.hibernate.validator and org.hibernate.search packages.

- Since you have configured classloader scoping for your application, JBoss loads the hibernate core classes, the hibernate entitymanager classes and the hibernate annotation classes from the upgraded jars packaged in your application.

- But when a class belonging to org.hibernate.validator or org.hibernate.search package is being requested for, JBoss sees that these classes are not present the jars packaged in your application. So it delegates the classloading to the parent classloader which looks for the classes in the jar files present in the JBoss lib folder (%JBOSS_HOME%/server/< serverName>/lib folder). Here it finds that these packages are present in the hibernate-annotations.jar (older version) and loads those classes from there. While doing so, it also loads the related classes from various other hibernate packages (which might already have been loaded by a different classloader - remember the classes loaded from the jars in your application). Ultimately, this results to the same classes being loaded twice by different classloaders. Later on when you access these classes in your application you might run into ClassCastExceptions.

This is just one example of what might go wrong. Infact, you might not get a clear picture based on this brief explanation. So if you are interested in understanding better (and have some time), then go through these forum discussions which have a lot more details (and which actually made me come up with this article):

ClassCastException for org.hibernate.search.event.FullTextIndexEventListener

Again the ClassCastException for org.hibernate.search.event.FullTextIndexEventListener

This time a NoSuchMethodException: org.hibernate.validator.ClassValidator.

So now that we have seen what kind of issues you might run into while upgrading, let's now come back to our original plan of upgrading hibernate :)

1) Enable classloader scoping through jboss-app.xml:



<jboss-app>

<loader-repository>
   org.myapp:loader=SomeClassloader
   <loader-repository-config>
      java2ParentDelegation=false
   </loader-repository-config>
 </loader-repository> 

  
</jboss-app>

Note: The string org.myapp:loader=SomeClassloader is any unique ObjectName

2) Include the following jar files in the application package:



Hibernate Core jar (3.2.6 GA)
Hibernate Annotations jar (3.2.x or 3.3.x)
Hibernate EntityManager jar (3.2.x or 3.3.x)
Hibernate Validator jar (3.0.x)
Hibernate Search jar (3.0.x)
and maybe even Lucene Core jar (lucene-core-2.2.0.jar)

Note: Please follow this page for downloading and figuring out the correct version of hibernate jars required (compatibility matrix).

So this is how your application packaging will look like finally:



MyApp.ear
 |
 |--- META-INF
 |     |
 |     |
 |     |--- application.xml
 |     | 
 |     |--- jboss-app.xml
 |
 |
 |--- lib
 |     |
 |     |--- [some jar files required by my app]
 |     |
 |     |--- hibernate3.jar (the hibernate core jar)
 |     | 
 |     |--- hibernate-annotations.jar 
 |     |
 |     |--- hibernate-entitymanager.jar 
 |     |  
 |     |--- hibernate-validator.jar 
 |     |
 |     |--- hibernate-search.jar 
 |     |
 |     |--- lucene-core-2.2.0.jar
 | 
 |
 |--- MyApp.war

That's it! The upgrade itself is simple enough. Note that, in this article, i have used an EAR as an example, but this applies to WAR files too. In WAR files, the jars will be placed in the WEB-INF/lib folder and the classloader configuration will be done through the jboss-web.xml file which will be in WEB-INF folder.

Why do i get NameNotFoundException while doing a JNDI lookup?

2007-10-06T01:07:00.001-07:00

Many a times when you are doing a lookup in the JNDI tree, you see javax.naming.NameNotFoundException. A simple code that does the lookup will look something like:


Context ctx = new InitialContext();
Object obj = ctx.lookup("somepath/somename");

This code just looks up the JNDI tree to get an object bound by the name "somepath/somename". Looks simple. However, chances are that you might even see this exception:


javax.naming.NameNotFoundException: somepath not bound
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
 at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
 at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
 at sun.rmi.transport.Transport$1.run(Transport.java:153)
 at java.security.AccessController.doPrivileged(Native Method)
 at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
 at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
 at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
 at java.lang.Thread.run(Thread.java:595)
 at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
 at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
 at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
 at javax.naming.InitialContext.lookup(InitialContext.java:351)

Look closely at the stacktrace. It shows that while looking up the JNDI tree it could not find the jndi name "somepath" (this name may vary). The reason is simple, the JNDI tree does not have any object bound by this name.

To quote the javadocs of this exception "This exception is thrown when a component of the name cannot be resolved because it is not bound."

So how do i know, what's the name to which my object is bound? Each application server, usually provides a JNDI view which can be used to see the contents of the JNDI tree. If you know what object you are looking for (ex: the name of the bean), then you can traverse this JNDI tree to see what name it is bound to. The JNDI view is specific to every application server.

To give an example, JBoss provides its JDNI tree view, through the JMX console. Here are the steps, one has to follow to check the JNDI tree contents on JBoss:

- Go to http://< server>:< port>/jmx-console (Ex: http://localhost:8080/jmx-console)
- Search for service=JNDIView on the jmx-console page
- Click on that link
- On the page that comes up click on the Invoke button beside the list() method
- The page that comes up will show the contents of the JNDI tree.

Here's an sample of how the output looks like(just a small part of the entire output):


java: Namespace

  +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
  +- SecurityProxyFactory (class: org.jboss.security.SubjectSecurityProxyFactory)
  +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
  +- comp (class: javax.naming.Context)
  +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
  +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  +- jaas (class: javax.naming.Context)
  |   +- dukesbank (class: org.jboss.security.plugins.SecurityDomainContext)
  |   +- HsqlDbRealm (class: org.jboss.security.plugins.SecurityDomainContext)
  |   +- jbossmq (class: org.jboss.security.plugins.SecurityDomainContext)
  |   +- JmsXARealm (class: org.jboss.security.plugins.SecurityDomainContext)
 

Global JNDI Namespace

  +- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)
  +- ebankAccountController (proxy: $Proxy75 implements interface com.sun.ebank.ejb.account.AccountControllerHome,interface javax.ejb.Handle)
  +- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)
  +- jmx (class: org.jnp.interfaces.NamingContext)
  |   +- invoker (class: org.jnp.interfaces.NamingContext)
  |   |   +- RMIAdaptor (proxy: $Proxy48 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
  |   +- rmi (class: org.jnp.interfaces.NamingContext)
  |   |   +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef)
  +- HTTPXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  +- ebankCustomer (proxy: $Proxy67 implements interface com.sun.ebank.ejb.customer.LocalCustomerHome)
  +- UserTransactionSessionFactory (proxy: $Proxy14 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
  +- ebankCustomerController (proxy: $Proxy77 implements interface com.sun.ebank.ejb.customer.CustomerControllerHome,interface javax.ejb.Handle)
  +- HTTPConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- TransactionSynchronizationRegistry (class: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple)
  +- ebankAccount (proxy: $Proxy68 implements interface com.sun.ebank.ejb.account.LocalAccountHome)
  +- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
  +- UILXAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
  +- UIL2XAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
  +- queue (class: org.jnp.interfaces.NamingContext)
  |   +- A (class: org.jboss.mq.SpyQueue)
  |   +- testQueue (class: org.jboss.mq.SpyQueue)
  |   +- ex (class: org.jboss.mq.SpyQueue)
  |   +- DLQ (class: org.jboss.mq.SpyQueue)
  |   +- D (class: org.jboss.mq.SpyQueue)
  |   +- C (class: org.jboss.mq.SpyQueue)
  |   +- B (class: org.jboss.mq.SpyQueue)

Let's see what this tells us. Let's consider the Global JNDI Namespace first. It contains (among other things) the following:


+- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)

This tells me that an object which implements com.sun.ebank.ejb.tx.TxControllerHome and javax.ejb.Handle interfaces is bound to the JNDI tree by the jndi-name "ebankTxController". So if at all i have to lookup this object, my lookup code would be something like:


Context ctx = new InitialContext();
ctx.lookup("ebankTxController");

Similarly in the same Global JDNI Namespace, we see :


+- queue (class: org.jnp.interfaces.NamingContext)
  |   +- A (class: org.jboss.mq.SpyQueue)

Make note of the nesting of the names here. This tells me that an object of type org.jboss.mq.SpyQueue is bound by the name "A under the path queue". So your lookup for this object should look like:


Context ctx = new InitialContext();
ctx.lookup("queue/A");

Now let's move on to the java: namespace in the JNDI tree view above. The difference between a Global JNDI namespace and the java: namespace is that, the object bound in the java: namespace can be looked-up ONLY by clients within the SAME JVM. Whereas, in case of Global JNDI namespace, the objects bound in this namespace can be looked-up by clients, even if they are not in the same JVM as the server. One would ask, how does this matter? Consider a standalone java program(client) which tries to lookup some object on the server (running in its own JVM). Whenever a standalone client is started (using the java command), a new JVM is instantiated. As a result, the server (which is started in its own JVM) and the client are running on different JVMs. Effectively, the client will NOT be able to lookup objects bound in the java: namespace of the server. However, the client can lookup the objects present in the Global JNDI namespace of the server.

So, why are we discussing these details, in a topic which was meant to explain the NameNotFoundException? Let's consider the java: namespace output above. There's a


+- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)

This tells me that there's an object bound to the name DefaultDS in the java: namespace. So my lookup code would be:


Context ctx = new InitialContext();
ctx.lookup("java:/DefaultDS");

As explained above, this code is going to return you the object, if this piece of code runs in the same JVM as the server. However, if this piece of code is run from a client in different JVM (maybe a standalone client), then it's going to run into NameNotFoundException. The reason i explained the java: and the Global JNDI namespace is that, sometimes people are surprised that even though the JNDI view shows that the object is bound in the java: namespace(with the same name as the one they pass to the lookup method), they still run into NameNotFoundException. The probable reason might be, the client is in a different JVM.

How do i use my own log4j properties or xml file in JBoss

2008-04-19T03:50:00.000-07:00

This article is mainly for those who had a hard time configuring "their own" log4j.properties or log4j.xml within their application on JBoss. For a brief background on this, please read through this JBoss wiki. As explained in that wiki, JBoss uses its own version of log4j.xml and log4j jar, making it difficult to use your own version of the log4j properties/xml files. The wiki also lists down the steps required to configure your application to use its own log4j config file. However, i have seen people complain in the forums that those steps either dont work for them or the steps are too involved and not worth a try.

People at JBoss had taken note of these issues (see the related JIRA) and starting JBoss-4.2.x, the steps involved to configure your own log4j config file in JBoss are pretty simple and straight-forward. In this example, i will try to explain these steps for a EAR file as well as a WAR file. The version that i am using here is JBoss-4.2.2GA (which is the latest stable version at this point). In the examples here, i use a log4j.properties file. The steps are the same even for a log4j.xml.

So here's what is required to get it working in a EAR file:

1) Create a log4j.properties and package it with your application and make it available in the classpath (i placed the log4j.properties file at the root of the EAR file).

2) Also package the appropriate version of log4j jar with your application (this step and the next step are important because you will have to ensure that log4j initializes separately for your application and picks up the log4j.properties file). Place this log4j jar file in the application package so that it is made available in the classpath (i placed it in a folder named lib of the EAR file - remember that any jars in the lib folder of the EAR are by default added to the classpath and made available to the entire application, starting JBoss-4.2.x version).

3) Enable classloader isolation for your application. This is necessary as explained in step#2. You will have to create a jboss-app.xml file and place it in the META-INF folder of the EAR. The jboss-app.xml looks like:


<jboss-app>
 <loader-repository>
   org.myapp:loader=MyClassLoader
   <loader-repository-config>
      java2ParentDelegation=false
   </loader-repository-config>
 </loader-repository>
   
</jboss-app>

This is how the EAR file would look like:



myApp.ear
  |
  |--- log4j.properties
  |
  |--- META-INF
  |     |
  |     |--- application.xml
  |     |
  |     |--- jboss-app.xml
  |
  |--- lib
  |     |
  |     |--- log4jxxx.jar

That's it! Your application now will use it own version of log4j config file as well log4j jar.

Steps involved for a WAR file are similar (If the WAR file is part of an EAR file, then you don't have to follow the steps below. The steps mentioned above for an EAR file are sufficient for a WAR inside an EAR):

1) Create a log4j.properties and package it with your application and make it available in the classpath (i placed the log4j.properties file in the WEB-INF/classes folder of the WAR).

2) Also package the appropriate version of log4j jar with your application (this step and the next step are important because you will have to ensure that log4j initializes separately for your application and picks up the log4j.properties file). Place this log4j jar file in the application package so that it is made available in the classpath (i placed it in a WEB-INF/lib of the WAR file).

3) Enable classloader isolation for your application. This is necessary as explained in step#2. You will have to create a jboss-web.xml file and place it in the WEB-INF folder of the WAR. The jboss-web.xml looks like:



<jboss-web>
    <class-loading java2ClassLoadingCompliance="false">
 <loader-repository>
 org.myapp:loader=MyClassLoader
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
 </class-loading>
</jboss-web>

This is how the WAR file would look like:


myApp.war
  |
  |--- WEB-INF
  |     |
  |     |--- web.xml
  |     |
  |     |--- jboss-web.xml
  |     |
  |     |--- classes
  |     |     |
  |     |     |--- log4j.properties
  | 
  |
  |--- lib
  |     |
  |     |--- log4jxxx.jar

Accessing a secure EJB through a standalone java client

2006-07-04T01:10:00.000-07:00

To access a secure resource(may be a EJB), from a standalone client, you need to do a JAAS login. Here's an simple example which shows how to implement the same. But before going to the example, here's the reason why we need to do a login. Consider a secured EJB "MyTestEJB", deployed on a app server. The normal proceedure that you follow in a web-application to lookup the EJB and invoke a method on the same is as follows:


Context context = new InitialContext(); 
//lookup the home object 
Object lookupObj = context.lookup("MyTestEJBHomeJndiName"); 
MyTestEJBHome home = (MyTestEJBHome) PortableRemoteObject.narrow(lookupObj, MyTestEJBHome.class); 
//create the bean object from the home object 
MyTestEJB myBean = home.create(); 
//invoke the method on the bean 
myBean.someMethod();

In the steps above, when the method create is called on the home object, the app server internally checks whether the user who is doing this operation, is authenticated and authorised to do the same. If not, it will throw a SecurityException. The above statements will usually work in a web-application where usually you have a login page to carry out the login process.

Now, consider the case with a standalone java client which has just got a main method and which needs to invoke the secure bean. The application server will have no knowledge about which user is trying to do the operations on the bean(is he authenticated or authorised?). This is the reason why the standalone client needs to do a JAAS login, to let the application server know which user is trying to do the operation on the bean. Now lets look at the code for doing the same. Here we have a standalone java client with a main() method:


package myapp;

import javax.ejb.CreateException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
import javax.security.auth.login.LoginContext;
import javax.security.auth.login.LoginException;
import java.io.Serializable;
import java.rmi.RemoteException;

/**
 *
 * Stand-alone client invoking a method on a secure EJB
 *
 */
public final class SomeStandAloneClient {


 /**
  * Default constructor
  *
  */
 public SomeStandAloneClient() {

 }

 /**
  * Main method
  *
  * @param args Command line arguments
  */
 public static void main(String[] args) {

  //obtain the username and password which are passed as part of command line arguments
  String userName = args[0];
  String password = args[1];

  System.out.println("Logging in user: " + userName);

  /*
   * The name of the file which will contain the login configurations
   */
  final String authFile = "someFilename.someExtension";

  /*
   * Set the filename above, as part of system property, so that while doing a login,
   * this file will be used to check the login configurations
   */
  System.setProperty("java.security.auth.login.config", authFile);

  /*
   * During the login process(i.e. when the login() method on the LoginContext is called),
   * the control will be transferred to a CallbackHandler. The CallbackHandler will be
   * responsible for populating the Callback object with the username and password, which
   * will be later on used by the login process
   *
   * The "MyCallbackHandler" is your own class and you can give any name to it. MyCallbackHandler
   * expects the username and password to be passed through its constructor, but this is NOT
   * mandatory when you are writing your own callback handler.
   *
   *
   */
  MyCallbackHandler handler = new MyCallbackHandler(userName,password);

  try {

   /*
    * Create a login context. Here, as the first parameter, you will specify which
    * configuration(mentioned in the "authFile" above) will be used. Here we are specifying
    * "someXYZLogin" as the configuration to be used. Note: This has to match the configuration
    * specified in the someFilename.someExtension authFile above.
    * The login context expects a CallbackHandler as the second parameter. Here we are specifying
    * the instance of MyCallbackHandler created earlier. The "handle()" method of this handler
    * will be called during the login process.
    */
   LoginContext lc = new LoginContext("someXYZLogin",handler);

   /*
    * Do the login
    */
   lc.login();

   System.out.println("Successfully logged in user: " + userName);


  } catch (LoginException le) {

   System.out.println("Login failed");
   le.printStackTrace();
   return;
  }

  try{

   /*
    * Now that the user has logged in, invoke the method on the EJB
    */

   Context context = new InitialContext();

   //lookup the home object
   Object lookupObj = context.lookup("MyTestEJBHomeJndiName");
   MyTestEJBHome home = (MyTestEJBHome) PortableRemoteObject.narrow(lookupObj, MyTestEJBHome.class);

   //create the bean object from the home object
   MyTestEJB myBean = home.create();

   //invoke the method on the bean
   myBean.someMethod();


  } catch (RemoteException re) {

   System.out.println("Remote exception: ");
   re.printStackTrace();
   return;
 
  } catch (NamingException ne) {

   System.out.println("NamingException: ");
   ne.printStackTrace();
   return;
 
  } catch (CreateException ce) {
 
   System.out.println("CreateException: ");
   ce.printStackTrace();
   return;
  }


 } //end of main()

} //end of SomeStandAloneClient

Now the CallbackHandler:


package myapp;

import java.io.IOException;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;

/**
 *
 * CallbackHandler which will be invoked by the login module during the login
 * process of the client. This is a simple CallbackHandler which sets the username
 * and password, which will be later used by the Login module for authorizing the
 * subject. This class only handles NameCallback and PasswordCallback. It throws
 * an UnsupportedCallbackException, if the Callback is other than the two mentioned
 * above.
 * The username and password are provided as input to this class through its constructor.
 *
 *
 */
public class MyCallbackHandler implements CallbackHandler {

 /**
  * Username which will be set in the NameCallback, when NameCallback is handled
  */
 private String username;

 /**
  * Password which will be set in the PasswordCallback, when PasswordCallback is handled
  */
 private String password;

 /**
  * Constructor
  * @param username The username
  * @param password The password
  */
 public MyCallbackHandler(String username, String password) {
  this.username = username;
  this.password = password;
 }

 /** 
  * @param callbacks Instances of Callbacks 
  * @throws IOException IOException 
  * @throws UnsupportedCallbackException If Callback is other than NameCallback or PasswordCallback 
  */ 
 public void handle(Callback callbacks[]) throws IOException, UnsupportedCallbackException {

  for(int i = 0; i < callbacks.length; i++) {
      if(callbacks[i] instanceof NameCallback) {
   NameCallback nc = (NameCallback)callbacks[i];
   nc.setName(username);
      } else if(callbacks[i] instanceof PasswordCallback) {
   PasswordCallback pc = (PasswordCallback)callbacks[i];
   pc.setPassword(password.toCharArray());
      } else {
   throw new UnsupportedCallbackException(callbacks[i], "Unrecognized Callback");
      }

  }
 }
}

The file containing the login configuration(in our case "someFilename.someExtension"):

someXYZLogin{
org.jboss.security.ClientLoginModule required;
};

Remember, the someXYZLogin configuration name is the same that i provided to the constructor of the LoginContext. The contents of the above file let the LoginContext know, which class will be actually responsible for doing the login. In this case, since i am using jboss, we have specified "org.jboss.security.ClientLoginModule" as the class.

Please make sure that the login configuration file is under the same directory from where you will be running your client.

The command to run your client is the same that you would use to run a normal java class:

java SomeStandAloneClient someUsername somePassword

The someUsername and somePassword will be the arguments that you will pass to the main() method.

This is just a simple example. Internally, there are a lot of things, that go on as part of login. The following link has a great explanation about the same(JAAS related things are explained starting from the "An Introduction to JAAS" section in that article). I highly recommend, to go through it atleast once:

Article on Security

Create your own logging level in log4j

2006-07-12T02:22:00.000-07:00

If you need to add your own logging level in log4j, then you can do it as follows. You will have to create your own class which will extend from Level. Here's a sample code for the same:

MyTraceLevel.java:


package org.myapp.log;

import org.apache.log4j.Level;
/**
 * My own {@link org.apache.log4j.Level} for logging. 
 * 
 * @author Jaikiran Pai 
 * 
 */ 
public class MyTraceLevel extends Level { 

 /** 
  * Value of my trace level. This value is lesser than 
  * {@link org.apache.log4j.Priority#DEBUG_INT} 
  * and higher than {@link org.apache.log4j.Level#TRACE_INT} 
  */ 
 public static final int MY_TRACE_INT = DEBUG_INT - 10; 
 
 /** 
  * {@link Level} representing my log level 
  */ 
 public static final Level MY_TRACE = new MyTraceLevel(MY_TRACE_INT,"MY_TRACE",7);

     /**
       * Constructor
        *
       * @param arg0
       * @param arg1
       * @param arg2
        */
     protected MyTraceLevel(int arg0, String arg1, int arg2) {
         super(arg0, arg1, arg2);

     }

     /**
      * Checks whether sArg is "MY_TRACE" level. If yes then returns 
      * {@link MyTraceLevel#MY_TRACE}, else calls 
      * {@link MyTraceLevel#toLevel(String, Level)} passing it 
      * {@link Level#DEBUG} as the defaultLevel.
       *
       * @see Level#toLevel(java.lang.String)
       * @see Level#toLevel(java.lang.String, org.apache.log4j.Level)
       *
       */
     public static Level toLevel(String sArg) {
         if (sArg != null && sArg.toUpperCase().equals("MY_TRACE")) {
             return MY_TRACE;
         }
         return (Level) toLevel(sArg, Level.DEBUG);
     }

     /**
      * Checks whether val is {@link MyTraceLevel#MY_TRACE_INT}. 
  * If yes then returns {@link MyTraceLevel#MY_TRACE}, else calls 
  * {@link MyTraceLevel#toLevel(int, Level)} passing it {@link Level#DEBUG}
  * as the defaultLevel
  *
       * @see Level#toLevel(int)
       * @see Level#toLevel(int, org.apache.log4j.Level)
       *
       */
     public static Level toLevel(int val) {
         if (val == MY_TRACE_INT) {
             return MY_TRACE;
         }
         return (Level) toLevel(val, Level.DEBUG);
     }

     /**
      * Checks whether val is {@link MyTraceLevel#MY_TRACE_INT}. 
      * If yes then returns {@link MyTraceLevel#MY_TRACE},
      * else calls {@link Level#toLevel(int, org.apache.log4j.Level)}
      *
      * @see Level#toLevel(int, org.apache.log4j.Level)
      */
     public static Level toLevel(int val, Level defaultLevel) {
         if (val == MY_TRACE_INT) {
             return MY_TRACE;
         }
         return Level.toLevel(val,defaultLevel);
     }

     /**
      * Checks whether sArg is "MY_TRACE" level. 
  * If yes then returns {@link MyTraceLevel#MY_TRACE}, else calls
  * {@link Level#toLevel(java.lang.String, org.apache.log4j.Level)}
  *
  * @see Level#toLevel(java.lang.String, org.apache.log4j.Level)
  */
 public static Level toLevel(String sArg, Level defaultLevel) {     
        if(sArg != null && sArg.toUpperCase().equals("MY_TRACE")) {
            return MY_TRACE;
        }
        return Level.toLevel(sArg,defaultLevel);
 }
}

Now, you will have to configure your log4j.xml:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> 
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"debug="false"> 
<!-- ================================= --> 
<!-- Preserve messages in a local file --> 
<!-- ================================= --> 
<!-- A size based rolling appender --> 
<appender name="FILE" class="org.apache.log4j.FileAppender"> 
<param name="File" value="D:/log/myLogFile.log"/> 
<param name="Append" value="false"/> 
<layout class="org.apache.log4j.PatternLayout"> 
<param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] %m%n"/> 
</layout> 
</appender> 
<!-- ============================== --> 
<!-- Append messages to the console --> 
<!-- ============================== --> 
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> 
<param name="Target" value="System.out"/> 
<param name="Threshold" value="INFO"/> 
<layout class="org.apache.log4j.PatternLayout"> 
<!-- The default pattern: Date Priority [Category] Message\n --> 
<param name="ConversionPattern" value="%d{ISO8601} %-5p [%c{1}] %m%n"/> 
</layout> 
</appender> 
<!-- ================ --> 
<!-- Limit categories --> 
<!-- ================ --> 
<category name="org.myapp"> 
<priority value="MY_TRACE" class="org.myapp.log.MyTraceLevel" /> 
<appender-ref ref="FILE"/> 
</category> 
<!-- ======================= --> 
<!-- Setup the Root category --> 
<!-- ======================= --> 
<root> 
<appender-ref ref="CONSOLE"/> 
</root> 
</log4j:configuration>

Here's a test program which can be used for testing whether the new log level that you introduced is being identified or not:

TestMyLogLevel.java:


package org.myapp.core; 

import org.apache.log4j.Level; 
import org.apache.log4j.Logger; 
import org.myapp.log.MyTraceLevel; 

/** 
 * Tests whether the new log level {@link org.myapp.log.MyTraceLevel#MY_TRACE} 
 * is working 
 * 
 * @author Jaikiran Pai 
 * 
 */ 
public class TestMyLogLevel { 

 /** 
  * Writes a log message with {@link org.myapp.log.MyTraceLevel#MY_TRACE} 
  * and another message with {@link Level#DEBUG}
       *
       * @param args
       */
 public static void main(String[] args) {
  Logger logger = Logger.getLogger(TestMyLogLevel.class);
  logger.log(MyTraceLevel.MY_TRACE,"I am MY_TRACE log");
  logger.log(Level.DEBUG ,"I am a debug message");
 }
}

Finally, here's the log file that got generated:


2006-07-12 13:45:40,633 MY_TRACE [org.myapp.core.TestMyLogLevel] I am MY_TRACE log 
2006-07-12 13:45:40,633 DEBUG [org.myapp.core.TestMyLogLevel] I am a debug message

Points to note:

- The int value that you specify for your log level is important. Here i have defined "MY_TRACE" log level is to be higher than the DEBUG level but lower than the TRACE level provided by log4j. So whenever you have set a priority level to DEBUG on the category(in your log4j.xml file), the MY_TRACE level logs will *NOT* make it to the log file.

How to create a Queue/Topic in JBoss?

2006-08-24T03:59:00.000-07:00

Queues/Topics are known as administered objects and in jboss they can be deployed through ServiceDotXml files. Let’s name our file, myapp-destination-service.xml. The contents of the file should look like:



<?xml version="1.0" encoding="UTF-8"?>

<server>
   <!--My queue, named: myAppQueue -->
  <mbean code="org.jboss.mq.server.jmx.Queue"
  name="jboss.mq.destination:service=Queue,name=myAppQueue">
    <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
  </mbean>
   <!-- My topic, named: myAppTopic -->
  <mbean code="org.jboss.mq.server.jmx.Topic"
  name="jboss.mq.destination:service=Topic,name=myAppTopic">
    <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
  </mbean>
    
  </server>

Place this file in your %JBOSS_HOME%/server/default/deploy directory and start the server.
(Note: If you are using the ‘all’ configuration or the ‘minimal’ configuration then you will have to place this file in the %JBOSS_HOME%/server/all/deploy or %JBOSS_HOME%/server/minimal/deploy directory, as appropriate).

The above queue/topic will be bound to the jndi name: queue/myAppQueue and topic/myAppTopic respectively.

Note:

1) The above file is meant for JBoss-3.2.3. Though there might be slight changes to later versions of JBoss, the basic configuration mechanism remains the same.

2) JBoss also comes with preconfigured queues/topics. These configurations can be found in the jbossmq-destinations-service.xml file which is present in %JBOSS_HOME%/server/default/deploy/jms directory

Lookup an EJB from a different application, deployed on the same server, in JBoss

2006-08-24T04:12:00.000-07:00

Question:
I have a web application through which i want to access an EJB which is deployed as a separate appliaction on the same server. How do i do it?
Answer:
In the web.xml of your war(the web application through which you want to access the EJB), have the following entry:



<ejb-ref>

<ejb-ref-name>GiveAnNameByWhichYouWouldLikeToReferTheBeanInYourWebApp</ejb-ref-name>
    <ejb-ref-type>session</ejb-ref-type>
    <home>packageName.ClassNameOfTheHomeObjectOfTheBeanYouWantToRefer</home>
    <remote>packageName.ClassNameOfTheRemoteObjectOfTheBeanYouWantToRefer</remote>
  </ejb-ref>

In the jboss-web.xml of your war, have the following entry:



  <ejb-ref>
      <!--The ejb-ref-name should be same as the one given in the web.xml above -->
      <ejb-ref-name>GiveANameByWhichYouWouldLikeToReferTheBeanInYourWebApp</ejb-ref-name>
      <!--Example:somecontext/somejndiName.YouWillFindThisJndiNameInTheJboss.xmlOfTheEJB-->
      <jndi-name>TheJndiNametoWhichTheBeanIsBound</jndi-name>
   </ejb-ref>

For more info, have a look at the dtds of web.xml (http://java.sun.com/dtd/web-app_2_3.dtd) and jboss-web.xml(http://www.jboss.org/j2ee/dtd)
In your code, do the lookup as:

 
Context ic = new InitialContext();
Object home=ic.lookup("java:comp/env/TheNameThatYouHadGivenInEjb-ref-nameTagOfJbossWeb.xml");

Here’s an example:

web.xml:


<ejb-ref>
    <ejb-ref-name>MyTestBean</ejb-ref-name>
    <ejb-ref-type>session</ejb-ref-type>
    <home>com.test.ejb.MyBeanHome</home>
    <remote>com.test.ejb.MyBeanRemote</remote>
  </ejb-ref>

jboss-web.xml:


 <ejb-ref>
   <ejb-ref-name>MyTestBean</ejb-ref-name>
   <jndi-name>myejb/test/MyTestBean</jndi-name>
  </ejb-ref>

Lookup code:


Context ic = new InitialContext();
  Object ejbHome = ic.lookup("java:comp/env/MyTestBean");

Convert exception stacktrace to String object

2006-08-24T04:47:00.000-07:00

Usually whenever a exception occurs, we use the method printStackTrace() on the exception object to display the stacktrace. However, if the stacktrace has to be stored into a String object then the following piece of code will prove handy:


  /**
     * Creates and returns a {@link java.lang.String} from t’s stacktrace 
     * @param t Throwable whose stack trace is required
     * @return String representing the stack trace of the exception
     */
    public String getStackTrace(Throwable t) {
        StringWriter stringWritter = new StringWriter();
        PrintWriter printWritter = new PrintWriter(stringWritter, true);
        t.printStackTrace(printWritter);
        printWritter.flush();
        stringWritter.flush(); 

       return stringWritter.toString();
    }

Custom reverse engineering strategy in Hibernate

2006-08-24T04:59:00.000-07:00

Hibernate has tools to create mapping files(hbm files) and domain model classes from database schemas(reverse engineering). can be used as part of ant task to do this. Hibernate creates the property names using its default reverse engineering strategy. Hibernate also, provides a way through which the user can specify his own custom reverse engineering strategy through which he can follow his own naming conventions etc…

There is a reversestrategy attribute which can be set to some custom class, which implements org.hibernate.cfg.reveng.ReverseEngineeringStrategy, in the . Here’s an example:


<jdbcconfiguration configurationfile="hibernate.cfg.xml"  

    packagename="${package.name}"  

    revengfile="hibernate.reveng.xml"  

    reversestrategy="org.myapp.hibernate.tool.SampleReverseEngineeringStrategy"/>

The org.myapp.hibernate.tool.SampleReverseEngineeringStrategy is our own custom class which implements org.hibernate.cfg.reveng.ReverseEngineeringStrategy. In this example, our SampleReverseEngineeringStrategy, overrides the columnToPropertyName(TableIdentifier table, String column) method to provide a custom implementation for generating property names out of a column name. Here’s the SampleReverseEngineeringStrategy code:


package org.myapp.hibernate.tool;  

import java.util.regex.Matcher;  
import java.util.regex.Pattern;  
import org.hibernate.cfg.reveng.DelegatingReverseEngineeringStrategy;  
import org.hibernate.cfg.reveng.ReverseEngineeringStrategy;  
import org.hibernate.cfg.reveng.TableIdentifier;  
/**  
 *  
 * @author Jaikiran Pai  
 *  
 */  
public class SampleReverseEngineeringStrategy extends DelegatingReverseEngineeringStrategy {  
/**  
  * Constructor  
  *  
  * @param delegate {@link org.hibernate.cfg.reveng.ReverseEngineeringStrategy}  
  */  
 public SampleReverseEngineeringStrategy(ReverseEngineeringStrategy delegate) {  
  super(delegate);  
 }  

/**  
  * Changes the default behaviour of naming the property. 
  
  * Does the following replacements(not neccessarily in the order) and returns the resulting  
  * {@link String} as property name:
  *  - Converts the first letter of the column to uppercase
  *  - Converts the letters following a ‘_’ character to uppercase in the column  
  *  - Removes any underscores present from column  
  *  
  * @see org.hibernate.cfg.reveng.DelegatingReverseEngineeringStrategy  
  * @see org.hibernate.cfg.reveng.ReverseEngineeringStrategy  
  *  
  * @param table {@link TableIdentifier}  
  * @param column  
  * @return Returns the propert name after converting it appropriately  
  */  
public String columnToPropertyName(TableIdentifier table, String column) {  

  String replacedColumn = replaceFirstLetterToUpperCase(column);  
   
   replacedColumn = removeUnderScoresAndConvertNextLetterToUpperCase(replacedColumn);  

   if (anyReplacementsMadeToOriginalColumnName(column,replacedColumn)) {  
  
  return replacedColumn;  

   }  

   /*  
    * Let DelegatingReverseEngineeringStrategy handle this  
    */  
   return super.columnToPropertyName(table, column);  
 }  

 /**  
  *  
  * Returns true if the originalString and replacedString are NOT equal  
  * (meaning there was some replacement done to the original column name). Else returns false.
  *  
  * @param originalString The original column name  
  * @param replacedString The column name after doing necessary replacements  
  * @return Returns true if the originalString and replacedString are NOT equal  
  * (meaning there was some replacement done to the original column name). Else returns false.  
  *   
  * @throws {@link NullPointerException} if originalString is null.  
  */  
 protected boolean anyReplacementsMadeToOriginalColumnName(String originalString, String replacedString) {  
  if (originalString.equals(replacedString)) {  
    return false;  

   }  

   return true;  
 }  

 /**  
  * Converts the first letter of the input to uppercase and  
  * returns the resultant {@link String}.  
  *   
  * Ex: If the input is startDate then the resulting {@link String}  
  * after replacement will be StartDate  
  *  
  * @param input The {@link String} whose contents have to be replaced  
  * @return Returns a {@link String} after doing the appropriate replacements  
  */  
 protected String replaceFirstLetterToUpperCase(String input) {  

   /*  
    * The pattern to match a String starting with lower case  
    */  
   final String startsWithLowerCasePattern = "^[a-z]";  
   
   Pattern patternForReplacingLowerCase = Pattern.compile(startsWithLowerCasePattern);  
   Matcher regexMatcher = patternForReplacingLowerCase.matcher(input);  

 /*  
  * This will hold the replaced contents  
  */  
 StringBuffer replacedContents = new StringBuffer();  

 /*  
  * Check whether the first letter starts with lowercase.  
  * If yes, change it to uppercase, else pass on the control to  
  * DelegatingReverseEngineeringStrategy  
  *  
  */  
 if (regexMatcher.find()) {  

  String firstCharacter = regexMatcher.group();  
  /*  
   * Convert it to uppercase  
   */  
  regexMatcher.appendReplacement(replacedContents,firstCharacter.toUpperCase());  
  regexMatcher.appendTail(replacedContents);  
  regexMatcher.reset();  
  
  /*  
   * Return the replaced contents  
   */  
    return replacedContents.toString();  

   }  

        //no replacements to do, just return the original input  
        return input;  

 }  

 /**  
  * Converts the letters following a ‘_’ character to uppercase and also removes  
  * the ‘_’ character from the input and returns the resulting {@link String}.   
  * Carries out a 2 pass strategy to do the replacements. During the first pass,  
  * replaces all the letters that immidiately follow a ‘_’ to uppercase.  
  * Ex: If the input is _start_Date__today_ then after the first pass of replacement, the  
  * resultant string will be _Start_Date__Today_  
  *   
  * This replaced {@link String} is then passed ahead for second pass (if no replacements were  
  * done during first pass, then the original {@link String} is passed). During the second pass  
  * the underscores are removed.  
  * Ex: If the input is _start_Date__today_ then after BOTH the passes the  
  * resultant string will be StartDateToday  
  *  
  * @param input The {@link String} whose contents have to be replaced  
  * @return Returns a {@link String} after doing the appropriate replacements  
  */  
 protected String removeUnderScoresAndConvertNextLetterToUpperCase(String input) {  

   /*  
    * The pattern which matches a String that starts with a letter immidiately after  
    * a ‘_’ character  
    */  
   final String stringFollowingUnderScore = "[.]*_[a-zA-Z]+";  

   Pattern patternForReplacingLowerCase = Pattern.compile(stringFollowingUnderScore);  
          Matcher regexMatcher = patternForReplacingLowerCase.matcher(input);  
          /*  
           * This will hold the replaced contents  
           */  
          StringBuffer replacedContents = new StringBuffer();  

          boolean foundAnyMatch = false;  

          while (regexMatcher.find()) {  
   foundAnyMatch = true;  
   String matchedString = regexMatcher.group();  
       /*  
          * The character immidiately following the underscore  
   * Example:  
          * If matchedString is _tMn then originalCharAfterUnderScore will be the  
          * character t  
          */  

        char originalCharAfterUnderScore = matchedString.charAt(1);  
         /*  
          * Convert the character to uppercase  
          */  

        String replacedCharAfterUnderScore = String.valueOf(originalCharAfterUnderScore).toUpperCase();  

        /*  
          * Now place this replaced character back into the matchedString  
          */  

        String replacement = matchedString.replace(originalCharAfterUnderScore,replacedCharAfterUnderScore.charAt(0));  

        /*  
   * Append this to the replacedColumn, which will be returned back to the user  
          */  
  regexMatcher.appendReplacement(replacedContents,replacement);  

     } //end of while  

        regexMatcher.appendTail(replacedContents);  
 regexMatcher.reset();  
 
 /*  
         * Now the input string has been replaced to contain uppercase letters after the underscore.  
         * Ex: If input string was "_start_Date_today" then at this point after the above processing,  
        * the replaced string will be "_Start_Date_Today"  
  * The only thing that remains now is to remove the underscores from the input string.  
        * The following statements do this part.  
        *  
        */  

      if (foundAnyMatch) {  
       return removeUnderScores(replacedContents.toString());  
       
   } else {  
     return removeUnderScores(input);  
     
   }  

 }  

 /**  
  * Removes any underscores present from input and returns the  
  * resulting {@link String}  
  * Ex: If the input is _start_Date__today_ then the resulting {@link String}  
  * after replacement will be startDatetoday  
  *
  * @param input The {@link String} whose contents have to be replaced  
  * @return Returns a {@link String} after doing the appropriate replacements  
  */  
 protected String removeUnderScores(String input) {  

   /*  
  * Pattern for matching underscores  
     */  
  Pattern patternForUnderScore = Pattern.compile("[.]*_[.]*");  

    Matcher regexMatcher = patternForUnderScore.matcher(input);  
  /*  
      * This will hold the return value  
   */  
    StringBuffer returnVal = new StringBuffer();  
       boolean foundAnyMatch = false;  
   
     while (regexMatcher.find()) {  
        foundAnyMatch = true;  

     String matchedString = regexMatcher.group();  

     /*  
       * Remove the underscore  
   */  
     regexMatcher.appendReplacement(returnVal,"");  

      }  

      regexMatcher.appendTail(returnVal);  
 regexMatcher.reset();  

      /*  
        * If any match was found(and replaced) then return the replaced string.  
        * Else return the original input.  
  */  
      if (foundAnyMatch) {  
        return returnVal.toString();  

      }  
 return input;  

 }  

}

In the example above, the columnToPropertyName method is overridden to do the following:

- Creates property names that start with a Capital case(By default, Hibernate creates property names in camel-case)
- Converts the letter, that follows a ‘_’ (underscore character) to uppercase in the property name
- Removes any underscores in the property name

Ex: If the column name is start_Date_today, then the resulting property name after using the SampleReverseEngineeringStrategy would be StartDateToday.

Here’s a documentation from Hibernate about Controlling Reverse Engineering

Webservice client using dynamic proxy

2007-04-18T03:59:00.000-07:00

In one of my previous posts, i explained how to create a WebService and access it from a simple client. If you look at the client code which accesses the webservice, you will find that the client is using the stubs that were created at deploy time. Such clients which use "static stubs" for accessing webservices are known as "Static Stub Clients". In such approach, the clients will have to have the stubs in their classpath.

Another approach of accessing the webservices is through Dynamic Proxies where the proxies are generated at runtime. I will be showing a simple client which uses dynamic proxies to access an webservice. I wont be explaining the steps to deploy the webservice (which i have already done in my other post). This example assumes that the webservice is already deployed on the server.

The client code will be accessing the HelloWorld service and invoking the sayHelloTo method on that service (Refer my other post to see how the service has been deployed onto the server)

Here's the code for the client:


package org.myapp.service.client;

import java.net.MalformedURLException;
import java.net.URL;

import javax.xml.namespace.QName;
import javax.xml.rpc.Service;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.ServiceFactory;

import org.myapp.service.HelloWorldService;

/**
 * Simple webservice client which uses dynamic proxy
 *
 * @author Jaikiran Pai
 */
public class DynamicProxyClient {

    public static void main(String args[]) {

        try {
            
            // ServiceFactory instance
            ServiceFactory serviceFactory = ServiceFactory.newInstance();
            System.out.println("Got the service factory");
            String wsdlURLString = "http://localhost:8080/axis/services/HelloWorld?wsdl";
            URL wsdlURL = new URL(wsdlURLString);
            String serviceName = "HelloWorldServiceService";
            String nameSpaceURI = "http://jaikiran.com";
            String portName = "HelloWorld";
            // get hold of the service by passing the URL of the wsdl and the
            // service name
            Service service = serviceFactory.createService(wsdlURL, new QName(
                    nameSpaceURI, serviceName));
            System.out.println("Got the service: " + service);
            // create the service proxy
            HelloWorldService serviceProxy = (HelloWorldService) service
                    .getPort(new QName(nameSpaceURI, portName),
                            HelloWorldService.class);
            System.out.println("Got the service proxy: " + serviceProxy);
            System.out.println("Invoking method on service proxy........");
            System.out.println(serviceProxy.sayHelloTo("Dynamic user"));

        } catch (ServiceException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (MalformedURLException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

}

1) Our first step would be to create a ServiceFactory instance, using which we can get access to a deployed service.


ServiceFactory serviceFactory = ServiceFactory.newInstance();

2) Once the ServiceFactory has been created, we will be getting hold of the service which is deployed on the server. To do this, we require
a) The url of the wsdl of the deployed service. In this example it will be http://localhost:8080/axis/services/HelloWorld?wsdl

b) The namespace uri. In this example it will be http://jaikiran.com (You can get this uri from the wsdl file)

c) The name of the service which you want to access. In this example it will be HelloWorldServiceService


String wsdlURLString = "http://localhost:8080/axis/services/HelloWorld?wsdl";
URL wsdlURL = new URL(wsdlURLString);
String serviceName = "HelloWorldServiceService";
String nameSpaceURI = "http://jaikiran.com";

// get hold of the service by passing the URL of the wsdl and the
// service name
Service service = serviceFactory.createService(wsdlURL, new QName(
                    nameSpaceURI, serviceName));

3) At this point you have got access to the service. But in order to invoke an method on the service, you will have to create a proxy (dynamic proxy) from this service. The Service class, has an API getPort, which creates the proxy. In order to create the proxy, we will have to pass the portName of the service (again, this can be obtained in the wsdl file), the namespace uri and the class type of the service. In this example the service interface is org.myapp.service.HelloWorldService, so we will be passing this as the class as follows:


String portName = "HelloWorld";
// create the service proxy
HelloWorldService serviceProxy = (HelloWorldService) service
                    .getPort(new QName(nameSpaceURI, portName),
                     org.myapp.service.HelloWorldService.class);

4) At this point we have got the service proxy which is of type org.myapp.service.HelloWorldService. We can now invoke our sayHelloTo method on this proxy:


System.out.println(serviceProxy.sayHelloTo("Dynamic user"));

Simple, isnt it? You have successfully invoked the webservice through a standalone client using dynamic proxy.

SyntaxHighlighter - Great and simple to use javascript utility

2008-07-11T22:23:00.000-07:00

This had been on my todo list for a long time now. I finally got the SyntaxHighlighter integrated in this blog.

Most of my posts in this blog include java code or xml content. And i always used to spend most of my time formatting the way the java code was rendered in the blog. I wont have to worry about that anymore. I am very much impressed by this excellent yet simple piece of utility! I have edited some of my earlier posts in the blog to make use of the SyntaxHighlighter. Editing wasn't a big deal. It was as simple as adding a "name" and "class" attribute to the "pre" tags.

Simple Webservice on JBoss using Axis

2006-12-10T02:07:00.000-08:00

Download the latest stable version of Axis from Axis Releases

1) Deploying Axis web application on JBoss:

I used Axis 1.4 on JBoss-4.0.4 GCA. Assuming you downloaded Axis to D: , copy the "axis" folder present in D:\Axis-1.4\webapps folder to %JBOSS_HOME%\server\default\deploy folder. The "axis" folder that you copied is nothing but an web application (containing of some servlets and jsps provided by Axis). In JBoss for a web application to be deployed, it has to be named *.war, so rename the "axis" folder in %JBOSS_HOME%\server\default\deploy to axis.war. At this point, the axis web application is ready to be deployed on JBoss. But before starting JBoss, delete the commons-logging-x.x.x.jar and log4j-x.x.x.jar present in %JBOSS_HOME%\server\default\deploy\axis.war\WEB-INF\lib directory, since JBoss maintains its own versions of these jars and packaging these jars in your application will throw exceptions of JBoss startup. After you have deleted these jars, start the JBoss server using the run.bat present in %JBOSS_HOME%\bin folder.

2) Verify Axis web application is deployed and running:

After JBoss has started successfully, go to the following URL to check whether axis is deployed properly:

http://localhost:8080/axis

If Axis was deployed successfully, you will see a welcome page which will have a few links, one of them named "List" which can be used to view the already deployed webservices. Axis by default comes with a few sample webservices which you can see on clicking the "List" link.

3) Writing our own webservice:

3a - The Java classes/interfaces:

Lets create a simple webservice which will echo a message to the user who passes his name. We will have an interface named HelloWorldService:


package org.myapp.service;

public interface HelloWorldService {
    
    public String sayHelloTo(String userName);

}

And here's the implementing class:


package org.myapp.service;

public class HelloWorldServiceImpl implements HelloWorldService {

    public String sayHelloTo(String userName) {
 
 //message
        String hello = "Hello " + userName + ". You are being watched";

        System.out.println(hello);
        
 //return the message
        return hello;
    }

}

Do you see anything special in this class or the interface? No, you wont. So how do you convert these into webservices? Read on...

3b - Create a wsdl file:

Now that we have the interface and the class ready, lets create a wsdl file out of these java classes. Axis comes with utilities which allow you to create the wsdl file from a java file. I wrote a small ant target which will do this for me:


<!--  Sets classpath for build  -->
<path id="classpath">
 <pathelement path="${java.class.path}" />
 <fileset dir="${lib}">
  <include name="**/*.jar" />
 </fileset>
 <pathelement path="${classes.dir}" />
</path>

<taskdef name="axis-java2wsdl" classname="org.apache.axis.tools.ant.wsdl.Java2WsdlAntTask" >
         <classpath refid="classpath"/>
</taskdef>

<target name="generateWSDL" description="Generates wsdl files from the java service interfaces">
 <mkdir dir="${wsdl.dir}"/>
 <axis-java2wsdl classpathref="classpath"
   output="${wsdl.dir}/HelloWorld.wsdl"
   location="http://localhost:8080/axis/services/HelloWorld"
   namespace="http://jaikiran.com"
   classname="org.myapp.service.HelloWorldService">

  <mapping namespace="http://jaikiran.com" package="org.myapp.service"/>
 
 </axis-java2wsdl>
</target>

Note: You can find the entire build.xml, that i used, at the end of this article.

You will require the org.apache.axis.tools.ant.wsdl.Java2WsdlAntTask class which is provided by axis to be in the classpath of Ant. This class comes bundled in the axis-ant.jar which i have included in the classpath of this task using the classpathref.

In this target you specify parameters like:
location - this is where the webservice will be deployed.
namespace - the namespace for your webservice
classname - the fully qualified name of the interface which you wrote in step 3a, above.
and also a mapping between the webservice namespace and your application packages.

This target will generate the wsdl file named HelloWorld.wsdl in the directory which you specified in the 'output' parameter of the target.

3c - Create the deploy.wsdd, undeploy.wsdd and the stubs:

Now that you have created a wsdl for your webservice, lets go ahead and create the deploy.wsdd (used for deploying a webservice on the server), undeploy.wsdd (used for undeploying a webservice from the server) and the required stubs for invoking the webservice from a java client.
Again, Axis provides utilities for creating these files. Axis accepts the wsdl file, which we created in step 3b as an input to create these files. Here's the Ant target which does this for us:


<taskdef name="axis-wsdl2java" classname="org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask" >
 <classpath refid="classpath"/>
</taskdef>
 
<target name="generateWSDD" description="Generates wsdd files from the wsdl files">
 <mkdir dir="${wsdd.dir}"/>
 <axis-wsdl2java
       output="${wsdd.dir}"
       deployscope="Application"
       serverside="true"
       url="${wsdl.dir}\HelloWorld.wsdl">
 </axis-wsdl2java>
</target>

This single target creates the deploy.wsdd, undeploy.wsdd and the stubs. As already mentioned, this target takes the wsdl file as an input which we have specified in the 'url' parameter of the axis-wsdl2java target. The files will be created in the directory mentioned in the 'output' parameter of this target. The deploy.wsdd file that gets generated will contain something like:


<!-- Use this file to deploy some handlers/chains and services      -->
<!-- Two ways to do this:                                           -->
<!--   java org.apache.axis.client.AdminClient deploy.wsdd          -->
<!--      after the axis server is running                          -->
<!-- or                                                             -->
<!--   java org.apache.axis.utils.Admin client|server deploy.wsdd   -->
<!--      from the same directory that the Axis engine runs         -->

<deployment
    xmlns="http://xml.apache.org/axis/wsdd/"
    xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

  <!-- Services from HelloWorldServiceService WSDL service -->

  <service name="HelloWorld" provider="java:RPC" style="rpc" use="encoded">
      <parameter name="wsdlTargetNamespace" value="http://jaikiran.com"/>
      <parameter name="wsdlServiceElement" value="HelloWorldServiceService"/>
      <parameter name="wsdlServicePort" value="HelloWorld"/>
      <parameter name="className" value="com.jaikiran.HelloWorldSoapBindingImpl"/>
      <parameter name="wsdlPortType" value="HelloWorldService"/>
      <parameter name="typeMappingVersion" value="1.2"/>
      <operation name="sayHelloTo" qname="operNS:sayHelloTo" xmlns:operNS="http://jaikiran.com" returnQName="sayHelloToReturn" returnType="rtns:string" xmlns:rtns="http://www.w3.org/2001/XMLSchema" soapAction="" >
        <parameter qname="in0" type="tns:string" xmlns:tns="http://www.w3.org/2001/XMLSchema"/>
      </operation>
      <parameter name="allowedMethods" value="sayHelloTo"/>
      <parameter name="scope" value="Application"/>

  </service>
</deployment>

You might notice that during all these steps we never mentioned our implementing class (HelloWorldServiceImpl) in any of the targets. As you can see above in the deploy.wsdd, Axis has created its own implementing class for the HelloWorldService and provided default implementations in that class. In the deploy.wsdd file, it mentioned the implementation class as follows:

<parameter name="className" value="com.jaikiran.HelloWorldSoapBindingImpl"/>

The reason why Axis created this implementing class is that it never knew that we had created our own implementation. The input that we provided to Axis for generating the wsdd files was a wsdl file through which Axis could never have known that we already have a implementation class.

Our next step would be to modify the deploy.wsdd file to mention our implementation class, in place of Axis'. So let's change the 'className' parameter to:

<parameter name="className" value="org.myapp.service.HelloWorldServiceImpl"/>

3d - Deploy the webservice onto the server:

Now we are almost ready to deploy the webservice onto the server. But before doing that, we will have to make the HelloWorldService.class and HelloWorldServiceImpl.class available in the server's classpath so that when we use this webservice, the server wont throw ClassNotFoundException. So let's compile these 2 classes and place the class files in the %JBOSS_HOME%\server\default\deploy\axis.war\WEB-INF\classes folder. Here's the Ant target that i used to compile these classes:


<target name="compile" description="Compiles java source code">
 <mkdir dir="${classes.dir}"/>
 <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${compile.src}" excludes="org/myapp/service/client/**/*.java"/>
</target>

Once this is done, we are ready to deploy the webservice onto the server. Axis again provides a utility to do this. Here's the target for deploying the service onto the server. This target just invokes the org.apache.axis.client.AdminClient java class passing it the deploy.wsdd file as an argument.


<target name="deployWebservice" description="Deploys the webservice onto the server, using the wsdd file and Axis' AdminClient">
 <java classname="org.apache.axis.client.AdminClient" classpathref="classpath" fork="true">
  <arg value="${wsdd.dir}/com/jaikiran/deploy.wsdd"/>
 </java>
</target>

Now that we have deployed the webservice, lets verify whether its deployed successfully. Let's again go to http://localhost:8080/axis . Here again lets click the "List" link to see all the available webservices. This time you will notice that our HelloWorld service is also listed over here. You can view the wsdl of this webservice, by clicking the wsdl link next to it. Our webservice has been deployed at http://localhost:8080/axis/services/HelloWorld as you can see from the wsdl contents. So let's hit this url. You will see a message like:

HelloWorld

Hi there, this is an AXIS service!
Perhaps there will be a form for invoking the service here...

4) Java client for accessing the webservice that we created:

Let's now create a simple java client which accesses the webservice that we just deployed on the server.
You might remember that in step 3c, we even created the stubs required to access the webservice. We will use these stubs in our java client to access the webservice. Here's the simple java client:


package org.myapp.service.client;

import com.jaikiran.HelloWorldService;
import com.jaikiran.HelloWorldServiceServiceLocator;

public class ServiceClient {

    /**
     * @param args
     */
    public static void main(String[] args) {

        try {
        
            //Get hold of the webservice using the locator provided by Axis  
            HelloWorldService helloWorldService = new HelloWorldServiceServiceLocator().getHelloWorld();

     //Invoke the method on the webservice  
            String message = helloWorldService.sayHelloTo("someUserName");
            
            System.out.println("Client received: " + message);
            
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

In this class you will notice that we are using HelloWorldServiceServiceLocator and the HelloWorldService which Axis generated for us. Running this client will invoke the webservice deployed on the server.

5) Ant build file

Here's the complete build.xml that i used as part of this example:


<?xml version="1.0" encoding="UTF-8"?>
<project name="MyApp" basedir=".." default="compile">
 
  <property name="conf.dir" location="${basedir}/conf" />
  <property name="build.dir" location="${basedir}/build"/>
  <property name="classes.dir" location="${build.dir}/classes" />
  <property name="compile.src" location="${basedir}/src" />
  <property name="lib" location="${basedir}/lib" />
  <property name="wsdl.dir" location="${build.dir}/wsdl" />
  <property name="wsdd.dir" location="${build.dir}/wsdd" />

  
  <!--  Sets classpath for build  -->
  <path id="classpath">
   <pathelement path="${java.class.path}" />
   <fileset dir="${lib}">
    <include name="**/*.jar" />
   </fileset>
   <pathelement path="${classes.dir}" />
  </path>

 
 
 <taskdef name="axis-java2wsdl" classname="org.apache.axis.tools.ant.wsdl.Java2WsdlAntTask" >
         <classpath refid="classpath"/>
   </taskdef>
 
 <taskdef name="axis-wsdl2java" classname="org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask" >
          <classpath refid="classpath"/>
 </taskdef>
 
 <target name="clean-all" description="Cleans(Deletes) the contents of all output directories">
  <delete dir="${classes.dir}"/>
  <delete dir="${wsdl.dir}"/>
  <delete dir="${wsdd.dir}"/>
 </target>
 
 <target name="build-all" description="Builds the entire project" depends="clean-all,compile,generateWSDL,generateWSDD,compileStubs,compile-client">
 
 </target>

 <target name="compile" description="Compiles java source code">
  <mkdir dir="${classes.dir}"/>
  <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${compile.src}" excludes="org/myapp/service/client/**/*.java"/>
 </target>
 
 <target name="compile-client" description="Compiles the webservice client" depends="compile">
  <mkdir dir="${classes.dir}"/>
  <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${compile.src}" includes="org/myapp/service/client/**/*.java"/>
 </target>
 
 <target name="generateWSDL" description="Generates wsdl files from the java service interfaces">
  <mkdir dir="${wsdl.dir}"/>
  <axis-java2wsdl classpathref="classpath"
           output="${wsdl.dir}/HelloWorld.wsdl"
           location="http://localhost:8080/axis/services/HelloWorld"
           namespace="http://jaikiran.com"
           classname="org.myapp.service.HelloWorldService">
     <mapping namespace="http://jaikiran.com" package="org.myapp.service"/>
  </axis-java2wsdl>
 </target>
 
 <target name="generateWSDD" description="Generates wsdd files from the wsdl files">
  <mkdir dir="${wsdd.dir}"/>
  <axis-wsdl2java
        output="${wsdd.dir}"
        deployscope="Application"
        serverside="true"
        url="${wsdl.dir}\HelloWorld.wsdl">
  </axis-wsdl2java>
 </target>
 
 <target name="compileStubs" description="Compiles the java classes(stubs) generated by Axis using the wsdl2java task">
  <mkdir dir="${classes.dir}"/>
  <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${wsdd.dir}"/>
 </target>
 
 <target name="deployWebservice" description="Deploys the webservice onto the server, using the wsdd file and Axis' AdminClient">
  <java classname="org.apache.axis.client.AdminClient" classpathref="classpath" fork="true">
   <arg value="${wsdd.dir}/com/jaikiran/deploy.wsdd"/>
  </java>
 </target>
 
 <target name="undeployWebservice" description="Undeploys webservice using the wsdd file and the Axis' AdminClient">
  <java classname="org.apache.axis.client.AdminClient" classpathref="classpath" fork="true">
   <arg value="${wsdd.dir}/com/jaikiran/undeploy.wsdd"/>
  </java>
 </target>
 
 <target name="runWebserviceClient" description="Executes the java client which access the webservice">
   <java classname="org.myapp.service.client.ServiceClient" classpathref="classpath" fork="true"/>
 </target>
  
</project>

6) The project directory structure

This is how my project's directory structure looks like (just in case you want to create a similar one):


Sample Webservice
 |
 |
 |------------- src
 |               | 
 |               |---- org
 |                      |--- myapp
 |                             |---- service
 |                                     |------- HelloWorldService.java
 |                                     |
 |                                     |------- HelloWorldServiceImpl.java
 |                                     |
 |                                     |----- client
 |                                              |-------- ServiceClient.java
 |
 |
 |------------- build
 |                |----- build.xml
 |
 |
 |------------- lib
                 | 
                 |----- activation.jar
                 |----- axis.jar
                 |----- axis-ant.jar
                 |----- commons-discovery-0.2.jar
                 |----- commons-logging-1.0.4.jar
                 |----- jaxrpc.jar
                 |----- mailapi_1_3_1.jar
                 |----- saaj.jar
                 |----- wsdl4j-1.5.1.jar

How to read a properties file in a web application

2007-01-04T06:01:00.000-08:00

The code to do this is pretty simple. But going by the number of people who keep asking this question, i thought i would post the code over here. Let's consider that you have a war file named SampleApp.war which has a properties file named myApp.properties at it's root :



SampleApp.war
   |
   |-------- myApp.properties
   |
   |-------- WEB-INF
                |
                |---- classes
                         |
                         |----- org
                                 |------ myApp
                                           |------- MyPropertiesReader.class

Let's assume that you want to read the property named "abc" present in the properties file:

----------------
myApp.properties:
----------------


abc=some value
xyz=some other value

Let's consider that the class org.myApp.MyPropertiesReader present in your application wants to read the property. Here's the code for the same:



package org.myapp;

import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

/**
 * Simple class meant to read a properties file
 * 
 * @author Jaikiran Pai
 * 
 */
public class MyPropertiesReader {

    /**
     * Default Constructor
     * 
     */
    public MyPropertiesReader() {

    }

    /**
     * Some Method
     * 
     * @throws IOException
     * 
     */
    public void doSomeOperation() throws IOException {
        // Get the inputStream
        InputStream inputStream = this.getClass().getClassLoader()
                .getResourceAsStream("myApp.properties");

        Properties properties = new Properties();

        System.out.println("InputStream is: " + inputStream);

        // load the inputStream using the Properties
        properties.load(inputStream);
        // get the value of the property
        String propValue = properties.getProperty("abc");

        System.out.println("Property value is: " + propValue);
    }

}

Pretty straight-forward. Now suppose the properties file is not at the root of the application, but inside a folder (let's name it config) in the web application, something like:



SampleApp.war
   |
   |-------- config
   |           |------- myApp.properties   
   |           
   |
   |-------- WEB-INF
                |
                |---- classes
                         |
                         |----- org
                                 |------ myApp
                                           |------- MyPropertiesReader.class

There will just be one line change in the above code:



  public void doSomeOperation() throws IOException {
        //Get the inputStream-->This time we have specified the folder name too.
        InputStream inputStream = this.getClass().getClassLoader()
                .getResourceAsStream("config/myApp.properties");
        
        Properties properties = new Properties();
         
        System.out.println("InputStream is: " + inputStream);
        
        //load the inputStream using the Properties
        properties.load(inputStream);
        //get the value of the property
        String propValue = properties.getProperty("abc");
        
        System.out.println("Property value is: " + propValue);
    }

That's all that is required to get it working.

How to package an application into a ear file

2006-10-30T22:01:00.000-08:00

This is for those who want to know the ideal and most common way an application is packaged in the form of an ear file. Here's how the application structure will look like:


myApp.ear
 |
 |--------- META-INF
 |            |
 |            |---------- application.xml
 |
 |--------- myEJB.jar
 |            |
 |            |--------- META-INF
 |            |            |
 |            |            |-------- ejb-jar.xml  
 |            |
 |            |------ org
 |            |         |----- myApp
 |            |                 |------- ejb
 |                                        |-------- *.class
 |
 |---------- myWeb.war
 |              |
 |              |----- WEB-INF
 |                      |------ web.xml
 |                      |
 |                      |------ jsp
 |                               |---- *.jsp
 |
 |---------- commonUtil.jar
               |
               |--------- org
                           |----- myApp
                                    |------ common
                                             |----- *.class

The application.xml present in the META-INF folder of the ear will contain the following:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application>
 <display-name>helloworld</display-name>
 
 <module>
  <java>commonUtil.jar</java>
 </module>
 
 <module>
  <web>
   <web-uri>myWeb.war</web-uri>
   <context-root>/myWeb</context-root>
  </web>
 </module>
 
 <module>
  <ejb>myEJB.jar</ejb>
 </module>
 
</application>

inverse attribute in Hibernate - What does it mean?

2006-08-24T08:35:00.000-07:00

This is the best explanation, that i have seen till date, about Hibernate's "inverse" attribute:
Meaning of "inverse" in Hibernate

Evict collection from Hibernate second level cache

2006-08-24T05:30:00.000-07:00

Hibernate allows persistent objects to be cached in its second level cache(The first level cache in Hibernate is the Session object which is ON by default). Applications can switch on the second level cache. When a object is being retrieved by the application through Hibernate, Hibernate first checks in its Session cache and then the Second level cache to see if the object has be retrieved already. If it finds it either the Session cache or the Second level cache, it will NOT fire a query to the database.
While configuring second level cache, the object can be cached and also the collections contained in the object can be cached. Have a look at the following example:


<hibernate-mapping default-lazy="false" > 
 <class name="org.myapp.ho.Parent" table="Parent"> 
    <b><cache usage="read-only" /> </b>
    <id name="id" type="Integer" column="ID" /> 
  <set name="myChildren"> 
     <b> <cache usage="read-only"/> </b>
     <one-to-many class="org.myapp.ho.Child"/> 
  </set> 
 </class> 
</hibernate-mapping>


<hibernate-mapping default-lazy="false" > 
   <class name="org.myapp.ho.Child" table="Child">
      <b><cache usage="read-only" /></b>
      <id name="id" type="Integer" column="ID" /> 
   </class> 
</hibernate-mapping>

Note that we have used the cache setting at 3 places:
1) The org.myapp.ho.Parent object
2) The "myChildren" collection in the org.myapp.ho.Parent object
3) The org.myapp.ho.Child object
When you configure a collection to be second level cached in Hibernate, it internally maintains a SEPERATE cache for these collection than the one which it uses to cache the parent objects. So in the example above, the “myChildren” will be cached separately than the org.myapp.ho.Parent object.
There might be cases where applications would want to evict objects from the cache. If its the Session cache from which the application has to evict the object then the call to Session.evict will cascade even to collections and will evict the collection from the *Session cache*. However, if the object(and the collections contained in it) have to be evicted from the second level cache, then the application has to *explicitly* call the evictCollection method on the SessionFactory to remove the *collection* contained in the Parent object. The reason behind this is, as already mentioned, the collections are cached separately, than the parent objects, in the second level cache.
So, in our example above, if we have to evict the Parent with id 500 and its collection from the second level cache, then here’s what has to be done:


SessionFactory sf = MyUtil.getSessionFactory();
//this will evict the Parent Object from the second level cache
sf.evict(org.myapp.ho.Parent.class,new Integer(500)); 
//this will evict the collection from the second level cache for the Parent with id=500
sf.evictCollection(org.myapp.ho.Parent.class.getName() +  ".myChildren", new Integer(500));

The first parameter to the evictCollection method is the ‘roleName’ of the collection. The roleName is formed as follows:

roleName = NameOfTheParentClass + "." + NameOfTheCollectionInsideTheParent

The second parameter the evictCollection method is the id of the parent object, to which this collection belongs.

How to enable Garbage Collection (GC) logs

2006-08-24T03:53:00.000-07:00

To enable GC logs, the -Xloggc:logFileName option will have to be passed when java command is being executed. Additionally if the detailed log of the GC is required, then an additional -XX:+PrintGCDetails option will have to be passed.

Example: java -Xloggc:D:/log/myLogFile.log -XX:+PrintGCDetails myProg

I get "log4j:WARN No appenders could be found for logger" message

2006-07-05T07:57:00.000-07:00

While using log4j in your application, sometimes you might encounter the following message:

log4j:WARN No appenders could be found for logger(somePackageName.someClassName).
log4j:WARN Please initialize the log4j system properly.

The reason why you see this message is that your log4j configuration file(i.e. log4j.xml or log4j.properties) is NOT found in the classpath. Placing the log4j configuration file in the applications classpath should solve the issue. If you want to find out how log4j tries to configure itself, have a look at my earlier post :

Know how log4j tries to configure itself

Know how log4j tries to configure itself

2006-07-04T02:44:00.000-07:00

Large number of applications use log4j for logging. Sometimes you may encounter cases where you sense that log4j is using some other configurations, other than the one that you expected it to use. You can debug the same by switching on the debug flag on log4j. Here's how you can do it:

Add -Dlog4j.debug to the command line. log4j will output info to std. out. telling you how it tries to configure itself.