On Saturday, August 06, 2011 2:59:00 AM Philippe Merle wrote: > > 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
Did you try hitting the endpoint with a client or just deploying? Since Message.Scope is used on the server side during request processing, I'm surprised it would work if your client didn't work. Dan > > 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 -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
