Hi,
Le 04/08/11 14:00, Glen Mazza a écrit :
For your specific question, I don't know.
Ok Sergey took the issue.
Google App Engine supports only SAAJ server-side, but JAX-WS is OK
for using a SOAP client[1]. This is a much better situation for the
long time before when neither[2] were supported, and a change Google
made because so many requested it. But even if we made your requested
change CXF-side, you would probably get tripped up soon in other ways
should you attempt to be using JAX-WS for a web service provider.
Further, GAE intentionally blocks certain packages so as to disable
certain functionality for its app hosting--it is not the packages it
is blocking, but the undesired functionality it does not want to
offer. I'm not certain CXF should be trying to circumvent GAE's
security goals, as that would result in a clumsier/buggier CXF
implementation (needing to reinvent wheels by no longer using well
established Java classes) and also GAE just blocking more and more
packages in order to thwart undesired functionality.
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.
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
