I did the conconfigurations you mentioned,, and now its working fine :) ,.,,, with no CXF libs at all.. anyway...
Thanks a lot for the help.. On 10/17/07, shaminda perera <[EMAIL PROTECTED]> wrote: > > 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 > > ----------- > > > >
