shaminda perera wrote:
Thanks Andrew,, But i didnt bundle any of the CXF jars in my WAR file to start with,,,,
Ok, we'll come back to that in a second. Irrespective of this when using CXF within a JBoss server you are still going to face problems with the fact that CXF and JBoss employ competing versions of some libraries. Depending upon where you have placed the CXF libs you may interpose the CXF versions before or after the JBoss ones in the classloader lookup path. If you do it one way you may upset JBoss. If you do it another way you may upset CXF. Welcome to classloader hell :-)
Given that you are getting the symptoms you described it looks as if the classloader is finding the CXF libraries first but is still being snookered by the JBoss resource mappings. Have you placed the CXF libraries in $JBOSS_HOME/lib? I believe this is the first place the classloader looks for an implementation class (after looking at a war /WEB-INF/lib, that is).
Whatever you have done, the reason I claim this is that i) you are getting incompatible super and subclasses and ii) the super class in question does not implement getProperty. So, the super class must be from the CXF jar. This means the incompatible subclass must be from the JBoss implementation jar. Although you have enabled prior access to the CXF saaj jar you have not disabled the resource mappings which load the JBoss saaj implementation jar. That is because none of the CXF libs contain a mapping file so none of them overrides the one provided by JBoss.
Another problem which occurs when you install the CXF libs this way is that legitimate JBoss apps which do not want to use CXF will be getting CXF versions of some classes. This is probably ok -- the latest (2.0+) CXF libs are likely to be later than the latest (4.2.1+) release JBoss libs -- but it is not the best way to organize things and, although it may work, there is no guarantee that there is no incompatibility here.
Now, conversely, if you were to place the CXF libs in the deploy directory or the server/<servername>/lib directory they would get loaded after the ones in $JBOSS_HOME/lib. This way round you would run the opposite risk that CXF code would get the wrong version of its libs since they would be preceded by alternatives found first in the JBoss lib directory. This is likely to be a worse problem since CXF needs some later versions of APIs than JBoss. Also, I think you would clobber some of the libs of the same name in the JBoss directory, i.e. you would still enforce a partial upgrade of the libs used by JBoss.
So, if your app is using CXF then it is probably best to ensure that it gets the libraries CXF wants it to have by bundling them in a .war file along with your app code. This also ensures that other apps do *not* get CXF libraries that they do not want. Of course, it also means a copy of the CXF libraries in every .war file . . .
If you want to persist in placing the CXF apps in the $JBOSS_HOME/lib directory rather than scoping the app libs inside a .war file then you will have to ensure that suitable resources are defined to map the MessageFactory and other classes to the appropriate implementations. i.e. you cannot just install the libs you also have to ensure that the factory mappings provided by the jboss implementation libs are correctly remapped.
regards, Andrew Dinn -----------
