Hi Philippe On Sat, Aug 6, 2011 at 1:59 AM, Philippe Merle <[email protected]> wrote: > 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 >
Nice, good news. Can you please try HTTPs, when you get a chance ? We have an issue which has been open for a while : https://issues.apache.org/jira/browse/CXF-3064 If you could just confirm it is still an issue and paste the stacktrace then it would help Thanks, Sergey >> >> 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 > > -- Sergey Beryozkin http://sberyozkin.blogspot.com Talend - http://www.talend.com
