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
