Hi Dan,
Le 08/08/11 18:09, Daniel Kulp a écrit :
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.
I tried the service with soapUI and replies are correct.
My service is Java-first interface, WSDL is generated at runtime, no
JAX-WS annotation in my interface.
Perhaps this implies this works well.
I will try an example with a WSDL interface first.
A+
Philippe
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
