[Building Sakai] life after axis

[John Bush]

I've seen from both php and .net client some weird stuff.  Like after
awhile you'll start getting errors saying method takes a string even
though you passed a string in and other things that appear to be
mismatches of types.

In php, I traced the problem back the caching of wsdls, restarts of
Sakai can confuse client code that is caching wsdls.  We limp along by
removing the jws classes before a restart which seems to help, but
once awhile this crops up again.  We have one client that relies on
axis as part of their logon routine from a portal, so any disruptions
are a huge problem.

We've also seen situations where under load if a whole bunch of
threads hit the server at the same time to compile the jws files, you
can get a whole bunch of compiliations happening that eat up permgen.

Its a bunch of weird stuff that in the end, leads to instability. I
believe axis 1 is known to have a bunch of memory leaks and thread
issues as well.

On Thu, Jan 30, 2014 at 4:43 PM, Steve Swinsburg
<steve.swinsburg at gmail.com> wrote:
> Hi John,
>
> Interesting idea and support this to modernise the code. However what is the
> issue that people are having when working with the axis 1.4 services?
>
> cheers,
> Steve
>
>
> On Fri, Jan 31, 2014 at 4:57 AM, John Bush <jbush at anisakai.com> wrote:
>>
>> There was discussion at Apereo camp about issues people are having
>> issues with the old axis 1.4 soap services, and it sounds like we are
>> not the only ones.  While REST is definitely the preferred integration
>> approach for anything new, a lot of people have legacy client code
>> that relies on the axis services.
>>
>> This is the plan I've been floating around in my head and have done a
>> little research into.
>>
>> We create a new webapp that uses cxf.  CXF can generate stubs from
>> wsdls.  So basically we take our existing wsdls, generate most of the
>> code, and then its a copy and paste affair from jws files to new
>> structure.  Wire in spring dependencies and bam you are done.
>>
>> The one issue is that you can't overload method names any more, I'm
>> assuming maybe that is part of a newer soap spec, but I'm not sure
>> there is anyway around that.  SakaiScript has a bunch of overloaded
>> method names that will need new names, but I'm guessing that would not
>> cause people too much pain to simply update in client code.
>>
>> I'm not going to put any energy into attempting to keep the same url
>> structure, as I think in cases where people have a hard time switching
>> over they could put rules in Apache or other things that front Sakai
>> to redirect to the new paths.
>>
>> So axis will still be there in Sakai 11, but for those that what to
>> move onto something more stable and not from 2006 they can.
>>
>> Any thoughts on this approach before I get started ?
>>
>> --
>> John Bush
>> 602-490-0470
>>
>> ** This message is neither private nor confidential in fact the US
>> government is storing it in a warehouse located in Utah for future
>> data mining use cases should they arise. **
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>
>



-- 
John Bush
602-490-0470

** This message is neither private nor confidential in fact the US
government is storing it in a warehouse located in Utah for future
data mining use cases should they arise. **