cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Merle <philippe.me...@inria.fr>
Subject Re: Google App Engine
Date Sat, 06 Aug 2011 00:59:00 GMT
Hi Daniel,

Le 05/08/11 16:20, Daniel Kulp a écrit :
>
> On Friday, August 05, 2011 4:08:32 PM Philippe Merle wrote:
>> 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
>> javax.xml.ws.handler.MessageContext.Scope 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:
>> javax.xml.ws.handler.MessageContext$Scope is a restricted class. Please
>> see the Google App Engine developer's guide for more details.
>
> Have you looked at the SOAP server side yet?    I'm wondering how they are
> restricting the server side but not the client side.    Most likely, if you
> drop down to the CXF server factory instead of Endpoint.publish(...), you may
> be able to even get CXF services working.

Good news: The server-side of Apache CXF JAX-WS frontend seems to work 
as it on GAE, at least for a simple example available at 
http://ow2-frascati.appspot.com/services/fibonacci-ws?wsdl

So Apache CXF JAX-WS and JAX-RS could work on GAE as shown by OW2 
FraSCAti in Google App Engine at http://ow2-frascati.appspot.com

>
> The MessageContext.Scope issue would still remain.   The
> AbstractJAXWSMethodInvoker.java and the subclass and possibly
> AbstractProtocolHandlerInterceptor.java would need some updates, but nothing
> really major.    We could potentially try doing a "Class.forName" on it and
> skipping the scoping if not found or something.
>
> Patches would be welcome.  :-)

Perhaps the next GAE release will resolve this issue. If not, then I 
would provide a patch for bypassing this GAE limitation.

A+
Philippe

>
>
> Dan
>
>
>
>
>> So I posted an issue on GAE:
>> http://code.google.com/p/googleappengine/issues/detail?id=5505
>> I am expecting that this issue will be take into account for a next GAE
>> release.
>>
>> 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.
>>
>> A+
>> Philippe
>>
>>> 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] http://code.google.com/appengine/articles/soap.html
>>> [2] http://code.google.com/p/googleappengine/issues/detail?id=1270
>>>
>>> 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 http://ow2-frascati.appspot.com/
>>>>
>>>> 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


Mime
View raw message