Thanks andrew for the detailed mail. This is what i am doing currently: I created a Web service client side related classes using the WSDL2Java tool provided by CXF, and then put just put these classes in a suitable package in the main web application. I didnt put any of the CXF provided jars/libraries in to the web application. Now when calling the web service i am getting this error ,,, that we are talking about.
Just thinking,,, the jdk's rt.jar also has some webservices/xml related classes,,, is my web service client using any of those as well? ,, or is it picking the libs from JBoss only.. I havent placed any CXF libraries in $JBOSS_HOME/lib ,, actually i havent placed them anywhere in Jboss or anywhere in my web application. I will try to do what you are mentioning in this mail, and get back to you.. On 10/17/07, Andrew Dinn <[EMAIL PROTECTED]> wrote: > > 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 > ----------- >
