[Building Sakai] life after axis report

[Sam Ottenhoff]

Right, SOAP webservices are disabled by default.  The new CXF webservices
respect this same property.

I think we should deprecate the Axis1 webservices, add the CXF code, modify
our documentation to recommend the new CXF endpoints if they need to
continue using these methods.  Then we can remove Axis1 from Sakai 11.
 Objections?

CXF also seems more performant.  I did a quick test: create 2000 users,
enroll them into a project site, and CXF SOAP webservices were about 10%
faster than the same Axis1 methods.

--Sam


On Tue, Feb 11, 2014 at 8:07 PM, John Bush <jbush at anisakai.com> wrote:

> yeah, I'm going to be fast tracking it into my 2.9 deployments, I
> don't see any reason to really keep it out of Sakai 10 for the reasons
> you brought up.  I think with Keitai, LTI and anything integration
> related sooner is better, just makes it easier for people to do more
> with Sakai.  To me this stuff is pretty safe.  I'm not sure you can
> really turn a webservice off other than blocking it, which is the ootb
> behavior anyway.
>
> On Tue, Feb 11, 2014 at 5:25 PM, Charles Severance <csev at umich.edu> wrote:
> > John,
> >
> > it would seem to me like a good idea to fast-track this branch into
> trunk before  Sakai-10.  Off by default via property would seem logical -
> but frankly there is no reason to keep it out given that it is 100% new
> functionality.
> >
> > /Chuck
> >
> > On Feb 11, 2014, at 5:17 PM, John Bush <jbush at anisakai.com> wrote:
> >
> >> Sam and I spent the day bringing our axis services forward into CXF see:
> >>
> >> https://source.sakaiproject.org/svn/webservices/branches/SAK-25678/cxf
> >>
> >> https://jira.sakaiproject.org/browse/SAK-25678
> >>
> >> Since it was so straightforward we went ahead and exposed everything
> >> as Rest along the way.  We need to do some more testing but we believe
> >> it should be as easy as pointing your client code to a new wsdl and
> >> maybe changing a few method names here and there (pretty isolated).
> >> The goal was to minimize the effect moving away from axis1 has on
> >> legacy client code.
> >>
> >> JWS was fun but had a lot of limitations, hard to debug, no compile
> >> time checking, and it simply breaks a lot, in my experience anyway.
> >> We simply lifted and shifted the code and wired in some annotations,
> >> not too bad at all.
> >>
> >> --
> >> 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. **
> _______________________________________________
> 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"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140212/8f8820b7/attachment.html