cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Merle <>
Subject Re: Google App Engine
Date Fri, 05 Aug 2011 14:08:32 GMT

Le 04/08/11 14:00, Glen Mazza a écrit :
> For your specific question, I don't know.

Ok Sergey took the issue.

>   Google App Engine supports only SAAJ server-side, but JAX-WS is OK 
> for using a SOAP client[1].  This is a much better situation for the 
> long time before when neither[2] were supported, and a change Google 
> made because so many requested it.  But even if we made your requested 
> change CXF-side, you would probably get tripped up soon in other ways 
> should you attempt to be using JAX-WS for a web service provider.  
> Further, GAE intentionally blocks certain packages so as to disable 
> certain functionality for its app hosting--it is not the packages it 
> is blocking, but the undesired functionality it does not want to 
> offer.  I'm not certain CXF should be trying to circumvent GAE's 
> security goals, as that would result in a clumsier/buggier CXF 
> implementation (needing to reinvent wheels by no longer using well 
> established Java classes) and also GAE just blocking more and more 
> packages in order to thwart undesired functionality.

After checking documentation, I see that GAE supports client-side part 
of JAX-WS but not server-side part.
I am more precisely identifying the problem I have:
* The CXF JAX-WS frontend uses the class in its JaxWsClientProxy class.
* The GAE's JRE Class White List indicates that this class is available.
* But when trying to access this enum class at runtime, an exception is 
thrown: java.lang.NoClassDefFoundError:$Scope is a restricted class. Please 
see the Google App Engine developer's guide for more details.

So I posted an issue on GAE:
I am expecting that this issue will be take into account for a next GAE 

Currently, I patched the JaxWsClientProxy class in order to not use 
Scope.APPLICATION (replaced by null). This is durty but this is just 
demo purpose.


> Rather than have CXF coded for GAE and non-GAE implementations, I 
> would say the correct and long term solution is to post a ticket item 
> on GAE asking them to allow certain packages--hopefully you'll get 
> enough support for them to yield, like [2].  But if they continue to 
> disallow it, to switch to a different app hosting provider.
> Glen
> [1]
> [2]
> On 08/04/2011 05:59 AM, Philippe Merle wrote:
>> Hi,
>> I am deploying a CXF-based application on Google App Engine. Have a look
>> at
>> I am using Apache CXF 2.4.1.
>> Its class
>> org.apache.cxf.transport.servlet.ServletContextResourceResolver uses two
>> classes (javax.naming.InitialContext and javax.naming.NamingException)
>> which are not allowed to be used on GAE. The use is done in the method
>> 'resolve':
>>       public final<T>  T resolve(final String entryName, final Class<T>
>> clz) {
>>           Object obj = null;
>>           try {
>>               if (entryName != null) {
>>                   InitialContext ic = new InitialContext();
>>                   try {
>>                       obj = ic.lookup(entryName);
>>                   } finally {
>>                       ic.close();
>>                   }
>>               }
>>           } catch (NamingException e) {
>>               //do nothing
>>           }
>>           ...
>> When I am commenting this try/catch block then the class
>> ServletContextResourceResolver seems to work well on GAE.
>> I would like to know:
>> * is this try/catch block really required?
>> * if not, could it be removed in a future version of CXF?
>> * if yes, which could be the solution in order to have this behavior
>> when needed and removed it when using CXF on GAE?
>> Thank you in advance and A+
>> Philippe Merle

View raw message