cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Merle <philippe.me...@inria.fr>
Subject Re: Google App Engine
Date Fri, 05 Aug 2011 13:55:24 GMT
Hi Sergey,

Le 05/08/11 14:46, Sergey Beryozkin a écrit :
> Hi Philippe
>
> On Fri, Aug 5, 2011 at 1:30 PM, Philippe Merle<Philippe.Merle@inria.fr>  wrote:
>> Hi Sergey,
>>
>> Le 05/08/2011 12:32, Sergey Beryozkin a écrit :
>>> Hi
>>>
>>> On Thu, Aug 4, 2011 at 10:59 AM, Philippe Merle<philippe.merle@inria.fr>
>>>   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?
>>>>
>>> I'm not sure when this code is used, I don't think we should have any
>>> tests in CXF, but
>>> it's most likely there for a reason, so I added the reflection-based
>>> code instead - I've added
>>> it to 2.5.0-SNAPSHOT only and will merge it to 2.4.2-SNAPSHOT - this
>>> should be a safe change,
>>> but would like to see if someone has any concerns, just in case
>> Thank you.
>>
>> Another possibility is to add:
>>
>>          } catch (ClassNotFoundException e) {
>>              //do nothing
>>          }
>>
>> Then this need not to use Java reflection and deal with the case of a JRE
>> which does not provide the InitialContext class.
> We'd still need to catch NamingException though, and may be
> NoClassDefFoundError, so
> using Throwable is needed...But I'm also not sure if GAE does some
> early resolution, in which
> case explicit InitialContext reference would still cause issues.
> Can you please try with Throwable only, but leaving explicit
> InitialContext code in place - if that works for you then
> I can revert most of my changes.

I did the following patch and this seems to work well on GAE:

     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();
                 }
             }
// BEFORE        } catch (NamingException e) {
         } catch (Throwable t) {
             //do nothing
         }

I am keeping the original code and just catching Throwable instead of 
NamingException.

A+
Philippe

>
> Cheers, Sergey
>
>> A+
>> Philippe Merle
>>


Mime
View raw message